I'm really confused everytime I come around this question, what characteristics would help one choosing SOAP over REST or the other way around?
I mean, besides the fact that REST has a compact format compared to SOAP, and the other "minor" or "technical" differences, what are the "obvious" differences that make one of them more suitable for a project and not the other?
Just for the record, I have read all of the other questions (1|2|3|4) regarding this matter on Stack Overflow, and not one of them answered my question.
The difference between REST and SOAP is fundamental, yet they're not that dissimilar. Ultimately, you still need to transfer exactly the same information in order to perform a particular abstract operation. It's entirely easy to make REST rather low-performing by choosing poorly what information to return, and SOAP with MTOM can transfer large binary chunks efficiently. There's even the possibility to use non-XML encodings and connected transports (e.g., XMPP) with SOAP that can make it more efficient than REST.
So don't worry about that!
A much more relevant thing to think about is that SOAP continues to have significantly more advanced tooling support in some languages, and that other languages strongly prefer REST. For example, if you want a Java client for your service, you'll be able to get going with SOAP in minutes: just put the WSDL location through a tooling engine and you've got yourself a basic client. On the other hand, if you're working with a Javascript client then you'll absolutely prefer to deal with the REST interface; Javascript works great with REST.
A key thing to note here is that you can have your service support both SOAP and REST at once (you might need to put them on different endpoints, but that's not very onerous). I do this with a service I support (using Java and Apache CXF) and the overhead of doing both is minimal: the key is that I need a clean abstract interface behind the scenes that both the SOAP and REST interfaces use.
If you just want a simple, visual guide to help you measure SOAP and REST against your applications requirements...
Vijay Prasad Gupta has put together a simple, helpful flow-chart.
Direct link to flow chart:
https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit
Link to article:
https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-needs
SOAP is a form of RPC and REST is architecture style that can scale with the web.
REST concerns about the following (copied from RESTful Web Services)
Addressability
Statelessness
Representations
Links and Connectedness
The Uniform Interface
Two great books on REST and have some discussions on the topic that you are interested in.
REST in Practice
Restful Web Services
Related
For a SaaS startup I'm involved in, I am building both a RESTful web API and a couple of client apps on different platforms that consume it. I think I've got the API figured out, but now I'm turning to the clients. As I've been reading about REST, I see that a key part of REST is discovery, but there seems to be a lot of debate between two different interpretations of what discovery really means:
Developer discovery: The developer hard-codes copious amounts of API details into the client, such as resource URI's, query parameters, supported HTTP methods, and other details that they've discovered through browsing the docs and experimenting with the API's responses. This type of discovery IMHO necessitates cool linkage and the API versioning question, and leads to hard coupling of the client code to the API. Not much better than if using a well-documented collection of RPC's it seems.
Runtime discovery - The client app itself is able to figure out everything it needs with little or no out-of-band information (presumably, only a knowledge of the media types the API deals with.) Links can be hot. But to make the API very efficient, a lot of link templating for query parameters seems to be needed, which makes out-of-band info creep back in. There are possibly other difficulties I haven't thought of yet since I haven't gotten to that point in development. But I do like the idea of loose coupling.
Runtime discovery seems to be the holy grail of REST, but I'm seeing precious little discussion about how to implement such a client. Almost all REST sources I've found seem to assume Developer discovery. Anyone know of some Runtime discovery resources? Best practices? Examples or libraries with real code? I'm working in PHP (Zend Framework) for one client. Objective-C (iOS) for the other.
Is Runtime discovery a realistic goal, given the present set of tools and knowledge in the developer community? I can write my client to treat all of the URI's in an opaque manner, but how to do this most efficiently is a question, especially over low-bandwidth connections. Anyway, URI's are only part of the equation. What about link templating in the Runtime context? How about communicating what methods are supported, aside from making a lot of OPTIONS requests?
This is definitely a tough nut to crack. At Google, we've implemented our Discovery Service that all our new APIs are built against. The TL;DR version is we generate a JSON Schema-like spec that our clients can parse - many of them dynamically.
That results means easier SDK upgrades for the developer and easy/better maintenance for us.
By no means the perfect solution, but many of our devs seem to like.
See link for more details (and make sure to watch the vid.)
Fascinating. What you are describing is basically the HATEOAS principle. What is HATEOAS you ask? Read this: http://en.wikipedia.org/wiki/HATEOAS
In layman's terms, HATEOAS means link following. This approach decouples your client from specific URL's and gives you the flexibility to change your API without breaking anyone.
You did your home work and you got to the heart of it: runtime discovery is holy grail. Don't chase it.
UDDI tells a poignant story of runtime discovery: http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration
One of the requirements that should be satisfied before you can call an API 'RESTful' is that it should be possible to write a generic client application on top of that API. With the generic client, a user should be able to access all the API's functionality. A generic client is a client application that does not assume that any resource has a specific structure beyond the structure that is defined by the media type. For example, a web browser is a generic client that knows how to interpret HTML, including HTML forms etc.
Now, suppose we have a HTTP/JSON API for a web shop and we want to build a HTML/CSS/JavaScript client that gives our customers an excellent user experience. Would it be a realistic option to let that client be a generic client application? No. We want to provide a specific look-and-feel for every specific data element and every specific application state. We don't want to include all knowledge about these presentation-specifics in the API, on the contrary, the client should define the look and feel and the API should only carry the data. This implies that the client has hard-coded coupling of specific resource elements to specific layouts and user interactions.
Is this the end of HATEOAS and thus the end of REST? Yes and no.
Yes, because if we hard-code knowledge about the API into the client, we loose the benefit of HATEOAS: server-side changes may break the client.
No, for two reasons:
Being "RESTful" is a property of the API, not of the client. As long as it is possible, in theory, to build a generic client that offers all capabilities of the API, the API can be called RESTful. The fact that clients don't obey the rules, is not the API's fault. The fact that a generic client would have a lousy user experience is not an issue. Why is it important to know that it is possible to have a generic client, if we don't actually have that generic client? This brings me to the second reason:
A RESTful API offers clients the option to choose how generic they want to be, i.e. how resilient to server-side changes they want to be. Clients which need to provide a great user experience may still be resilient to URI changes, to changes in default values and more. Clients doing batch jobs without user interaction may be resilient to other kinds of changes.
If you are interested in practical examples, checkout my JAREST paper. The last section is about HATEOAS. You will see that with JAREST, even highly interactive and visually attractive clients can be quite resilient to server-side changes, though not 100%.
I think the important point about HATEOAS is not that it is some holy grail client-side, but that it isolates the client from URI changes - it is assumed you are using known (or developer discovered custom) Link Relations that will allow the system to know which link for an object is the editable form. The important point is to use a media type that is hypermedia aware (e.g. HTML, XHTML, etc).
You write:
To make the API very efficient, a lot of link templating for query parameters seems to be needed, which makes out-of-band info creep back in.
If that link template is supplied in the previous request, then there is no out-of-band information. For example a HTML search form uses link templating (/search?q=%#) to generate a URL (/search?q=hateoas), but nothing is known by the client (the web browser) other than how to use HTML forms and GET.
I have a question around SOA.
Are SOAP and REST both considered approaches for implementing a service-oriented architecture?
I know that REST is a style, thus this leads me to this question.
Yes, they both can be considered approaches for implementing a SOA. I suppose you could say REST is a style, but then you'd have to say SOAP is one too. I would simply consider them different techniques to accomplish the same end. SOAP mimics a Remote Procedure Call and REST is inline with how the web (http) was designed.
When creating/adapting services to work in a SOA architecture the interfaces exposed can be whatever you desire as long as the consumers have the ability to process the response.
For the sake of giving a more concise answer, I will interpret REST as being a HTTP interface which can perform the CRUD operations, perhaps responding to requests with an XML or JSON object.
SOAP tends to lend itself to more complex operations on the service side, the libraries and involved XML's of SOAP introduces complexity to the system.
If all you require is the representation of resources which can be accessed through simple CRUD operations it is worth considering implementing a REST interface to reduce complexity, even if the service will run along side services with SOAP interfaces. All that would be required is the consumer of the service is able to deal with the RESTful style responses as well as acting as a SOAP client.
There would be arguments for consistency across the service to improve maintainability and ease of development, but this isn't a necessity and should only be included in the decision process.
When including a messaging bus into the design, heterogeneous services can be dealt with even more effectively by inserting standard transforms (XSLT, custom) into the process which can translate the response from services into a standard format understood by the system as a whole.
If you simply ask whether both of them can be implemented using Service Oriented Architecture - yes they do. They can even be used both at once in a single SOA-based project.
If you are asking whether SOAP or REST should be used - there is no answer unless you provided project specifications.
SOAP and REST are ways of building services.
SOAP is XML based and, in theory, supports more than just HTTP, and has standards for interface definition (WSDL), and things like security (WS_Security).
REST is a style for doing web services in a resource-oriented manner using a defined set of web operations (GET, POST, etc), but defines very little else.
However, SOA is about much more than just a bunch of services. Choosing REST or SOAP is the easy part.
This is a multi-part question. I just watched a very interesting presentation on YQL by the lead developer (a graduate of my MS program). While it was very compelling, and I am looking forward to trying it out, I am wondering if anyone knows of alternative frameworks for querying multiple web service APIs to make them appear seamless, the apparent purpose of YQL?
Yahoo's strategy has been to create XML schema definitions that bind a given web service's parameters into their YQL Open Table query parameters, which I think is very clever. Is there any tool that attempts (perhaps I am naive here) to automate the discovery of parameters in say a REST API? I am aware that with SOAP APIs, because there is a published WSDL, it makes automation easier, but is there yet no way to do this with REST? Is anyone trying?
Yes people are trying to produce description languages for REST. The most popular effort is WADL. There are lots of questions about WADL here on SO. Is it a good idea? In my opinion no.
REST does not need a discovery model beyond what it already has with hypermedia, because is trying to solve a problem at a different architectural layer than web services. Web services deliver data to an application's business logic/domain model. REST is about delivering content and behaviour to a presentation layer.
How about an analogy? Think of the different between an object and struct in C++. A struct is just simple data that some client process is going to manipulate. That's what a web service does, it returns a chunk of data, a struct. Sure maybe it did a bunch of server side processing to produce the result, but the end result is a lump of data. A REST interface delivers an object. i.e. It contains both data and the methods that can be used to manipulate that object. By definition, if you understand the uniform interface and you understand the returned media type, you already know what you can do with the response. Discovery mechanisms are redundant.
If you find this hard to believe, the think about the web. How does a web browser discover web pages? The web has no formalized discovery mechanism, and yet there is a world of information out there that we can discover with a web browser.
There is this little website http://zachgrav.es/yql/tablesaw/ which indeed auto-discovers parameters in a REST api and turns it into a YQL compatible table.
There are two ways to find information. Either you use a 100% unambiguous language or you use a natural language. Anything in between like YQL is doomed to fail because it delivers neither and works well only with the examples its authors tout.
I blogged about this at http://zscraper.wordpress.com/2012/05/30/enough-with-crawling-2. My personal stance is that you'll always get the most accurate results if you do your homework first, i.e. study the target domain and figure out how to query it unambiguously.
To answer your question and give you an alternative -- try Bobik. This is a cloud-backed scraping service that you control via REST API. Compose your "queries" in traditional syntax (Bobik supports Javascript, JQuery, XPATH and CSS) and call Bobik to run them from any client-side environment (webpages, mobile apps, or your server).
Hope this helps.
To describe RESTful we can say that every resource has its own URI. Using HTTP GET, POST, PUT and DELETE, we can operate on these resources. All resources are representational. Whoever wants to use our resources can do so via a browser or REST client.
That's the main idea of a RESTful architecture. This architecture allows services on the internet. So why does this architecture need WADL? What does WADL offer that standard HTTP does not? Why does WADL need to exist?
The purpose of WADL is to define a contract. Contract specifies how one party can call another.
When you create a web application from scratch, you don't need contract and WADL.
When you integrate your system with the other system and you can communicate clearly with their development team, you don't need contract and WADL (because you can make a phone call to make things clear).
However when you integrate a complex enterprise system with several others complex enterprise systems maintained by several different companies (or federal institutions), then believe me you want to have a communication contract defined as strictly as possible. Then you need WADL or Open Specification. Need it badly.
People with weak enterprise background tend to see entire IT as a collection of separated web applications developed independently. But enterprise reality is sometimes tough. Sometimes you can't even call or write to the people developing the application you have to integrate with. Sometimes you communicate with a legacy application that is no longer maintained--it just runs and you need to figure out how to communicate with it properly. In such conditions you need a contract because it saves your ass.
Actually client generation is the minor feature of the contract definition. It's just a toy. Contract enforces bad communicators to communicate integration rules clearly. This is the main reason to use WADL or Open Specification or whatever.
Using WADL implies that you just might be gracious enough to actually define the data / documents you are passing back and forth. Say you are passing some XML fragments, they might actually be part of a defined schema.
Whether or not you use the DL to generate code is not very important to me. What matters, in my subjective opinion, is that it is important to have a formal agreement on interfaces between business partners. Even if what is passed is obvious, it helps to identify who has to fix what later if somebody changes the previous interface.
Data format is just as much a part of an interface as verb names.
WADL appeals to people coming from the SOAP world where it is common to use a code generator to create client side code based on the WSDL. I don't think that mechanism is useful in REST as it creates client code that is coupled to server endpoints.
I believe that if you properly define your media-types and use hypermedia within those media-types, then it is not necessary to have WADL. The description of the available end-points is contained within the media-type definitions themselves. And if you are now saying to yourself, but application/xml doesn't contain any information about available hyperlinks, then I say BINGO. That's why I don't think application/xml and application/json are appropriate media-types for REST. I'm not saying don't use XML or JSON, just don't use the generic media type name.
The other appeal of WADL is for the purpose of documenting REST services. Unfortunately, it leads developers down the wrong path as WADL attempts to document server-side end points. Documenting a REST services should focus primarily on the media-types. A client developer should be able to write a REST client without knowing any url other than the root url.
WADL allows you to generate code, tests and documentation. Actually there are few very useful tools utilizing WADL, you can see some examples here. The problem with the "pure" REST, as described in Fielding's dissertation, is writing clients supporting Hypermedia (imagine writing Java Swing-based client application for example). With WADL this task is completely automated, and it's a huge advantage in my view. Testing becomes a way easier too.
Before I give my explanation, let me say that most pure REST extremists will deride it to the ends of the earth. I don't agree with them, as i'd rather get something done, but just so you know.
WADL is a description of a web service API, a little like WSDL is for SOAP type web services, that is designed to be more in tune with RESTful interfaces (something WSDL is poor at).
It's primary usage in my experience is to allow you to generate client code that can call the service (handy if it's a very large API, which literally saves hours of work). It also serves the purpose of documenting a REST-like interface.
REST specifies nothing about WADL.
When you want to expose the REST services ,the best way is to generate WADL and share with consumer(similar to WSDL in SOAP based web services).WADL is used to describe service all in on place.
WADL is not necessary to use. But, If you are working with complex existing application and you want to implement REST service call by replacing the EJB/SOAP service call, Then it is very safe and good practice that you use WADL. By using WADL generate client side java stubs you will be in sync with the service.
You can generate client side java stub using WADL file with help of wadl2java maven plugin.
I mean, really, what is the point of SOAP?
Web services have been around for a while, and for a while it seemed that the terms 'SOAP' and 'Web service' were largely interchangeable. However SOAP always seemed unwieldy and massively overcomplicated to me.
Then REST came along, and suddenly web services made sense.
As Joel Spolsky says, give a programmer a REST URL, and they can start playing with the service right away, figuring it out.
SOAP is obfuscated behind WSDLs and massively verbose XML, and despite being web based, you can't do anything as simple as access a SOAP service with a web browser.
So the essence of my question is:
Are there any good reasons to ever choose SOAP over REST?
Are you working with SOAP now? Would it be better if the interface was REST?
Am I wrong?
As Joel Spolsky says, give a programmer a REST URL, and they can start playing with the service right away, figuring it out.
Whereas if the service had a well specified, machine readable contract, then the programmer wouldn't have to waste any time figuring it out.
(not that WSDL/SOAP is necessarily an example of good implementation of a well specified contract, but that was the point of WSDL)
Originally, SOAP was a simple protocol which allowed you to add a header to a message, and had a standardized mapping of object instances to XML structures. Putting the handling metadata in the message simplified the client code, and meant you could very simply persist and queue messages.
I never needed the header processing details when I built SOAP services back in 2001. This was pre-WSDL, and it was then normal to use GET for getting information and queries (no different to most applications which claim to be REST; REST has more in terms of using hyperlinks for service discovery) and POST with a SOAP payload to perform actions. Those actions which created resources would return the URL of the created resource to the client, and the client could then GET the resource. I think it's the fact that WSDL made it easy to think only in terms of RPC rather than actions which create resources which made SOAP lose the plot.
The way I see it, SOAP might be more "flexible", but as a result it's just way too complicated (you mentioned the WSDL, which is always a stumbling block to me personally).
I get REST. It's simple. The only downside I might see is that you are limiting yourself to those 4 basic actions against a single resource, which might not exactly fit the way you view your data.
The topic is well-discussed in Why is soap considered to be thick.
While doing some research to understand some of the answers here (especially John Saunders') I found this post http://harmful.cat-v.org/software/xml/soap/simple
SOAP is more insane than I thought...
The point of WSDL was auto-discovery. The idea was that you wouldn't have to write client code, it would be auto-generated.
BTW. next step beyond WSDL are Semantic Web Services.
If you don't need the features of the WS-* series of protocols; if you don't need self-describing services; if your service cannot be completely described as resources, as defined by the HTTP protocol; if you don't like having to author XML for every interaction with the service, and parse it afterwards; then you need SOAP.
Otherwise, sure, use REST.
There's been some question about the value of a self-describing service. My imagination fails me when it comes to imagining how anyone could fail to understand this. That's on me. Still, I have to think that anyone who has ever used a service much more complicated than "Hello, world" would know why it is valuable to have someone else write the code that accepts parameters, creates the XML to send to the service, sends it, receives the response, then turns that back into objects.
Now, I suppose this might not be necessary when using a RESTful service; at least not with a RESTful service that does not process complex objects. Even with a relatively simple service like http://www.earthtools.org/webservices.htm (which I've used as an example of calling a RESTful service), one benefits from understanding the structure of the returned data. Even the above service provides an XML Schema - it unfortunately doesn't describe the entire response. Given that schema one still has to manually process the XML, or else use a tool to produce serializable classes from the schema.
All of this happens for you when the service is described in a WSDL, and you use a tool like "Add Service Reference" in Visual Studio, or the svcutil.exe program, or I-forget-what-the-command-is-in-Eclipse.
If you want examples, start with the EarthTools services, and go on to any other services with more complicated messaging.
BTW, another thing that requires self-description is description of the messaging patterns and protocols supported by the service. Perhaps that's not required when the only choices are HTTP verbs over HTTP or HTTPS. Life gets more complicated if you're using WS-Security and friends.
I find that SOAP fits in most appropriately when there is a high probability that a service will be consumed by corporate off the shelf (COTS) software. Because of the well specified contract employed by SOAP/WSDL most COTS packages have built in functionality for consuming such services. This can make it easy for BPM/workflow tools etc. to simply consume defined services without customization. Beyond that service use case REST tends to be my goto web service implementation for applications.
Well it appears now that the WSI agree that SOAP no longer has a point as they have announced they will cease to exist as an independent entity.
Interesting article about the announcement and some commentary here: http://blogs.computerworlduk.com/simon-says/2010/11/the-end-of-the-road-for-web-services/index.htm
Edited to be completely accurate in response to John Saunders.
I think SOAP appeals to the Java and .net crowd who may be more familiar with the old CORBA and COM and less familiar with internet technologies.
REST also has one major drawback: there is very little guidance on how to actually implement such a system. You will find significant variations on how many of the public RESTful APIs have been designed. In fact many violate key aspects of REST (such as using GET for manipulation or POST for retrieval) and there are disagreements over fundamental usage (POST/GET vs POST/GET/PUT/DELETE).
Am I wrong?
"You're not wrong, Walter, you're just... :)"
Are there any good reasons to ever choose SOAP over REST?
SOAP, to my understanding adheres to a contract, thus can be type checked.
SOAP is a lightweight XML based structured protocol specification to be used in the implementation of services . It is used for exchanging
structured information in a decentralized, distributed environment. SOAP uses XML technologies for exchanging of information over any transport layer protocol.
It is independent of any particular programming model and other implementation specific semantics. Learn More about XML
SOAP Messaging Framework
XML-based messaging framework that is
1) Extensible : Simplicity remains one of SOAP's primary design goals. SOAP defines a communication framework that allows for features such as security, routing, and
reliability to be added later as layered extensions
2) Inter operable : SOAP can be used over any transport protocol such as TCP, HTTP, SMTP. SOAP provides an explicit binding today for HTTP.
3) Independent : SOAP allows for any programming model and is not tied to Remote procedure call(RPC). SOAP defines a model for processing individual, one-way messages.
SOAP also allows for any number of message exchange patterns (MEPs) .Learn more about SOAP