REpresentational State Transfer (REST).
REST provides you with abilities that are similar (such as making a stateless request and receiving an XML response) to typical web services but with less overhead on the server than standard SOAP calls. This means that if you have a heavy load on the server, throughput can be faster. In addition, because REST behaves like a regular web request except that you are returning XML strings, implementing REST can be easier for non-SOAP-experienced developers.
Of course, all of this does have a cost. REST requires clients to do more work in receiving the XML because they have to parse it themselves. In contrast, SOAP has Web Services Description Language (WSDL) and XML Schema Definition (XSD) for strong typing to generate the client code.
My only gripe with RESTful services is that everyone seems to implement them slightly differently. There seems to be a textbook definition of how to use them; the URI has a hierarchy describing what it is you are looking for. The user can then use that hierarchy while sending over different types of requests (for example, GET, DELETE). Those requests will determine what the code does. For example, you could send over /address/123 Main St with the DELETE request, and it would tell the server to delete the address 123 Main St. Then an XML response would be returned. In this example, the response would probably be some sort of confirmation. However, not many RESTful components seem to use this method of calling.
The request should be a totally stateless request, and the URL you are sending over does not care about what was previously sent or any session. The URL is sent to the server, a request is made, and an XML response is returned.
REST provides you with abilities that are similar (such as making a stateless request and receiving an XML response) to typical web services but with less overhead on the server than standard SOAP calls. This means that if you have a heavy load on the server, throughput can be faster. In addition, because REST behaves like a regular web request except that you are returning XML strings, implementing REST can be easier for non-SOAP-experienced developers.
Of course, all of this does have a cost. REST requires clients to do more work in receiving the XML because they have to parse it themselves. In contrast, SOAP has Web Services Description Language (WSDL) and XML Schema Definition (XSD) for strong typing to generate the client code.
My only gripe with RESTful services is that everyone seems to implement them slightly differently. There seems to be a textbook definition of how to use them; the URI has a hierarchy describing what it is you are looking for. The user can then use that hierarchy while sending over different types of requests (for example, GET, DELETE). Those requests will determine what the code does. For example, you could send over /address/123 Main St with the DELETE request, and it would tell the server to delete the address 123 Main St. Then an XML response would be returned. In this example, the response would probably be some sort of confirmation. However, not many RESTful components seem to use this method of calling.
The request should be a totally stateless request, and the URL you are sending over does not care about what was previously sent or any session. The URL is sent to the server, a request is made, and an XML response is returned.
