WEB SERVICES
A Web service, in very broad terms, is a method of communication between two applications or electronic devices over the World Wide Web (WWW). Web services are of two kinds: Simple Object Access Protocol (SOAP) and Representational State Transfer (REST).
SOAP OR REST ??
This is of course a very controversial topic, but at the same time, most new services are REST for a number of reasons. I won't cover the differences between the two (as that is well documented) but more the reasons I think you'd build a new service, today (2012) using REST:
- REST is much simpler, basically just building on top of HTTP
- You can test (and debug) REST services using a web browser or something like curl or httpie. Yes this is technically possible with SOAP as well, but you have to somewhat understand the SOAP schema.
- Similarly, you can build a REST client as long as you have a way to access HTTP. SOAP requires a SOAP-capable library
- REST is more of a style and builds on top of HTTP, whereas SOAP is an entire protocol on top of HTTP (which is also a protocol)
- SOAP ends up with crazy extension protocols like WS-Security, WS-Encryption (which, essentially, are incredibly complex designed-by-committee solutions to problems the rest of the internet solved for HTTP a couple decades ago)
If you look around at some of the major APIs on the internet (eg Google, Facebook, Twitter, etc) you'll find a lot of REST, and little to no SOAP. Those that do have SOAP interfaces are deprecating or dropping them completely, because there's very little reason to stick with it any more.
In fact, many of the big services are going a step further and only offering their REST services with JSON formatting, as opposed to XML or both, because like REST over SOAP, JSON has a lot of advantages in terms of size and simplicity over XML that it doesn't make much sense to continue supporting XML.
There are also almost no drawbacks to REST compared to SOAP.
About the only practical consideration I can think of is from a client perspective. With SOAP (because of WSDL, assuming you produce one) you can point a SOAP-capable IDE at the service (such as VisualStudio) and it will generate a native client proxy API based on the remote service. This is somewhat nice in terms of getting up and running quickly, but has its own set of drawbacks: it forces you to use the objects defined in the service (whereas with REST, you can use your own object definitions as long as the data maps in), and depending on how the remote service handles versioning (or not) and how you use it, you may end up having to update major chunks of your app because of something as simple as a naming change.
From the server perspective, I really can't see any technical benefits to choosing SOAP over REST whatsoever.
TL;DR: SOAP is not necessarily bad, it's just that REST is better.
This article quickly compares one with the other -
| REST | SOAP |
| Assumes a point-to-point communication model–not usable for distributed computing environment where message may go through one or more intermediaries | Designed to handle distributed computing environments |
| Minimal tooling/middleware is necessary. Only HTTP support is required | Requires significant tooling/middleware support |
| URL typically references the resource being accessed/deleted/updated | The content of the message typically decides the operation e.g. doc-literal services |
| Not reliable – HTTP DELETE can return OK status even if a resource is not deleted | Reliable |
| Formal description standards not in widespread use. WSDL 1.2, WADL are candidates. | Well defined mechanism for describing the interface e.g. WSDL+XSD, WS-Policy |
| Better suited for point-to-point or where the intermediary does not play a significant role | Well suited for intermediated services |
| No constraints on the payload | Payload must comply with the SOAP schema |
| Only the most well established standards apply e.g. HTTP, SSL. No established standards for other aspects. DELETE and PUT methods often disabled by firewalls, leads to security complexity. | A large number of supporting standards for security, reliability, transactions. |
| Built-in error handling (faults) | No error handling |
| Tied to the HTTP transport model | Both SMTP and HTTP are valid application layerprotocols used as Transportfor SOAP |
| Less verbose | More verbose |
No comments:
Post a Comment