Can REST be purely used as a lightweight SOAP alternative (without really worrying about the nouns and verbs associated)? What I really hate about SOAP is the overhead it adds in terms of message payload and I like the usage of JSON in REST which should make communication pithy.
For ease of client-side integration, what is the best way to provide the definitions from the server to the client. Reading other posts post1 post2, there seem to be a lot of animosity against providing a WSDL like alternative (viz. WADL?). If the server and client are both aware of changes that might happen and if my reason for using REST is only #1 above, then why is it such a bad thing?
1 Answers
Can REST be purely used as a lightweight SOAP alternative (without really worrying about the nouns and verbs associated)?
Not if you still want to call it REST. REST by definition cares about the nouns and verbs. If you just want to use JSON to do RPC, go ahead. But what you'll end up with could be better described as "SOAP lite".
For ease of client-side integration, what is the best way to provide the definitions from the server to the client. Reading other posts post1 post2, there seem to be a lot of animosity against providing a WSDL like alternative (viz. WADL?). If the server and client are both aware of changes that might happen and if my reason for using REST is only #1 above, then why is it such a bad thing?
WSDLish "definitions" are considered bad because REST is not really an RPCish style protocol. With REST, you start with a single entry point and from there, you follow URLs provided by the server in the response. The client shouldn't need to have "definitions" for method calls and such -- the standard HTTP verbs should have standard, obvious and appropriate effects -- and it shouldn't need even the prior knowledge of how to construct a URL; the URL should be provided in the response. For example, if you're getting a user profile, a field of the response might be the url for the user. If you're viewing an order, each item within it would have a URL (as a field!), which you could use to retrieve info on the item. Such as that.

- 84,970
- 20
- 145
- 172