Which is the simpler approach for implementing web services, REST or SOAP/WSDL? I've been thinking about how they compare.
Supporters of the REST approach claim that it's simpler than SOAP. (By SOAP, we really mean SOAP and WSDL, since SOAP is just a data format, not a service.) Amazon Web Services
implements both, and there are claims
that 85% of the AWS traffic is REST (therefore only 15% SOAP). I have no idea if these numbers are accurate, or how they change over time, but let's suppose they're accurate. This is the main REST drumbeat, that REST is simpler than SOAP.
So is REST simpler? Hmmm, from who's perspective?
REST leads to lots of little URLs--one per remotely-accessible object, plus URLs for listing objects and creating new instances. For example,
could provide access to the
instance whose ID is #12345. No non-trivial app can nor should have that many static URLs or HTML/XML/whatever pages, so the way REST works is to map lots of logical URLs to objects/resources in the app. This puts complexity on the client to figure out which of a seemingly endless list of URLs to invoke for the desired behavior, and puts complexity on the host to map this vast set of URLs to useful behavior or objects. SOAP has fewer URLs, basically one per port type defined in WSDL.
Thanks to all the URLs in REST, each URL's behavior is pretty darn simple. There are only four operations: GET, PUT, POST, and DELETE (although it appears that POST can be overloaded to do lots of things depending on the request document; see What is REST?
). So assuming the operations' behavior is truly as intuitively obvious as it's supposed to be, once you've got the URL, invoking the behavior should be simple. A SOAP/WSDL service has fewer URLs, basicly one per port type, but lots of operations, as listed in the WSDL.
SOAP and REST seem to agree on XML as the data format of choice. But a SOAP/WSDL format requires a particular XML schema for the SOAP body (a schema for the request and another for the reply). A REST service, in theory, can support multiple formats; the client and provider negotiate which format to use for a particular invocation. Will these negotiations really make REST simpler? Or will a typical REST service maintain simplicity by only supporting a single format?
These are points upon which learned men can disagree. Do you prefer lots of URLs and a small, constant set of fine-grained operations (REST)? Or fewer URLs, each hosting a larger, application/service-specific set of potentially course-grained operations (SOAP/WSDL)? Do you want to support one set of XML data formats (SOAP/WSDL) or potentially negotiate the data format every time (REST)? Which do you think is simpler?
Some other thoughts along these lines:
I've discussed how REST and SOAP/WSDL
compare, and sidestepped the issue of which alternative is necessarily better. But I think I have a simple litmus test
you might want to apply.
It seems to me that REST is not object-oriented.
Here's why I think REST is not OO. Recall that the best way to implement a service in J2EE
is with a stateless session bean. A SSB is one object that provides a group of related services/operations, such as everything you might want to do with your bank or bookstore. A client looks up an SSB, invokes services to its heart's content, then discards it. The services are meaningful domain operations, such as
REST doesn't work this way. You'd have a URL for the shopping cart and another URL for the book. Which do you use? You could tell the cart "add book X" or tell the book "add to my cart," but REST doesn't have operations like that, it just has GET and PUT. So I suppose you do something like this:
- GET the book from its URL to get its UID
- GET your shopping cart from its URL
- modify the shopping cart document to add the book
- PUT the shopping cart back to its URL
Who thinks that's fun?! Is there a better way to do this in REST? That's definitely not simpler than
So I don't necessarily want to say that SOAP and WSDL are the most OO protocol imaginable for Web services, but they seem a lot better than REST. The more OO web services are, the better, and SOAP/WSDL seems like the better of the two approaches.
Web services are generally thought of as SOAP
over HTTP. Another approach is REST.
An alternative web services technology is Representational State Transfer (REST)
, an approach that tries to be much simpler than SOAP. The idea is that HTTP isn't just the transport for a web service, it is the web service. By this definition, the web itself is a REST system.
With REST, each resource/object exposed to the web has its own logical URL for accessing it. (The web server maps the URL to the object so that each object doesn't need its own static page or predefined URL.) The services are the HTTP verbs GET, PUT, and DELETE, for viewing, updating, and destroying the object. (There's also POST, which is a heck of a lot like PUT.)
I haven't programmed in REST (yet), but from what I've read, a REST web service for browsing and ordering products might work like this:
The HTTP request and response can contain any HTTP data. It's usually XML (MIME type
), using schemas defined by the services provider (
in this example). A service may support multiple data representations, then negotiate with the client to determine which to use for that particular client.
A common debate theme within the REST community is how the HTTP verbs (GET, PUT, POST, and DELETE) are supposed to work in a web services context. People describe their services as "I think this is RESTful," meaning that the URLs represent resources and the service implements the verbs properly/as expected. But the developers often seem uncertain of themselves, debate the tradeoffs, and sometimes disagree.
There is no formal Java API for using REST. It's so much like good ol' HTTP, perhaps you don't need a new API or library, just a servlet that performs GET, PUT, POST, and DELETE as defined in REST. (I don't think you can necessarily assume that the average Java servlet is automatically REST compatible!) There's support for REST in Apache Axis 2.0
and an article on implementing REST in Java, "The REST of the Web
For more info:
Aug 18 Update:
On advice from my commenters (see below; thanks for the comments, guys!), an HTTP GET should have no side effects (makes sense). Creating an order so that it can be returned is obviously a side effect, so GET is not appropriate. Seems like if you wanted your web site/web services to be read-only, you'd only support the GET verb.
Accordingly, I've changed the single GET command that I imagined would create and return an order to two commands: a POST to create the order, which returns the URL for the order, and then a GET to retrieve the order. Two commands instead of one seems like more work, and is definitely more round trips across the network, but apparently this is the way REST (and HTTP) works.
I'm still not clear on the difference between PUT and POST. Notice that I now POST to create an order and PUT to update it. Is this correct?
Not to get grouchy here, but REST is supposed to be simpler than SOAP. Seems like when the verbs are somewhat unclear like this, and when it takes multiple commands and round trips to perform one logical action, it takes away from the simplicity.
Aug 20 Update:
Again, thanks to my commenters for helping me understand REST better.
OK, so PUT is like a setter method (and GET is like a getter method; duh). POST is like "perform an action." This is a true service method, where the service can be anything. It's like document-style SOAP (not RPC-style), where you don't tell the receiver what to do, you just pass the receiver some data and say "process this," and the receiver figures out how to process it.
So GET, PUT, and DELETE are pretty straightforward, actions performed on the resource/object specified by the URI. POST is the miscellaneous verb, telling the resource to do whatever processing it thinks is appropriate.
Where is this stuff documented (besides trying to decipher the HTTP spec)? Seems like there ought to be a simple "REST Style" guide that explains this pretty briefly, but I haven't found one.
I appreciate both commenters' insights, but I found this suggestion a bit concerning: Use the HTTP 201 (created) response
, put the URI for the new order in the response's Location response-header field
, and put the order XML doc in the response's entity-body
. I'm kinda impressed by how creative this approach is, but again it confuses me even more as to why proponents seem to think that REST is so much simpler and easier than SOAP. You need to not only understand these HTTP verbs, but also status codes and header fields? Seems to me that any particular provider's REST services are going to need a lot of documentation, not unlike SOAP or Java or any other programming. How's this simpler?
A reader recently asked: Which web sites (if any) do you frequent to keep up with Java goings-on?
Hmm, that's a good question. Here are a couple you might want to check out.
I do a lot of my learning by reading books, so one of my very first blog postings was What You Should Be Reading
. This is a theme that has come up a number of times in my blog, so Google for that
. Likewise, check out a frequent recommendation of mine, the ISSW Recommended Reading List
, which is mostly articles and web sites, not books, so that they're freely and immediately accessible.
The reader proposed one possibility for a good web site to learn about Java: The Server Side
. I tend to find The Server Side to be kind of a super market tabloid of a Java news site; more interested in shocking than educating. There, I've said it, let the hate mail begin. (sigh) When I peruse The Server Side, what I find is lots of announcements for new versions of frameworks I've never heard of, which doesn't make me feel more knowledgeable about how to use Java. To anyone who wants to defend The Server Side: What would be useful is for you to highlight sections of the web site for learning about Java, and thereby prove what a good educational site it is; I'd like to know.
There are other Java web sites which tend to be educational and helpful. My collegue Kyle Brown publishes and comments occasionally
, which seems to actually have informative articles. Along the same lines, jGuru
seems good. A performance-specific site is Java Performance Tuning
; a similar site is Precise Java
. (Also in the Google list of Java performance sites
is one called Nawa Shibari
, but judging from the root page, I'd say it seems to be something very different! Is this where Java performance enthusiasts go when they're not tuning Java?!)OnJava
is O'Reilly's take on things. Javalobby
is kind of the closest thing Java has to a political action committee
. And finally, at the risk of simply endorsing my own employer, there are lots of good articles in the developerWorks
' zones on Java
, WebSphere Application Server
, IBM WebSphere Developer Technical Journal
, Rational Application Developer
(and the older WebSphere Studio zone
), and so on.
That should give you some stuff to browse for a while. Hope you find it helpful.
Aug 23 Update:
Another helpful site is java.net
, run by Sun as a newsie addition to the main Java Technology
James Governor of RedMonk
commented on What is a Web Service?
, quibbling with my statement that SOAP is the "most common" technology for implementing Web services. He makes a good point; at the same time, I stand by my statement.
As I've already noted in REST vs. SOAP/WSDL
, Amazon claims (according to Tim O'Reilly) that its AWS traffic is 85% REST, 15% SOAP. So REST proponents claim anecdotal evidence
like this means REST is more popular.
They may be right--if SOAP and REST went up against each other in the People's Choice Awards
(or their technical equivalent, the JDJ Reader's Choice Awards
), REST might win the popular vote. Hobbyists seem to prefer REST.
But I'm interested in the enterprise application
market, not the hobbyist market, and enterprise applications that use Web services use SOAP. I consult with customers using IBM J2EE products (WAS
, etc.), and they're using SOAP. JAX-RPC
, support for SOAP over HTTP and WSDL Web services, is part of J2EE
. J2EE doesn't have any support for REST, unless you count servlets
(which is kind of all you need for REST).
So the logic is kind of circular--J2EE supports SOAP, not REST; so that's what J2EE apps use--but nevertheless, that's how I see enterprise applications implementing Web services these days. SOAP is the established standard, REST is the opponent fighting SOAP for mindshare and trying to gain supremacy. Maybe it will; we'll see.
But for now at least, SOAP is the "most common" Web services technology.
I've talked about
how Web 2.0 makes web sites available through web services APIs. Another way of looking at all this is in terms of the MVC paradigm/pattern.
(MVC) approach separates an application's model from its view. The model is the app's data wrapped by the functions/services it performs. The view is a UI for displaying the model to the user. An app should use MVC to separate its view(s) from its model, so that the model can support multiple views, can run without any views (headless), and so that changes to the model's implementation don't affect the views' impls and vise versa.
As I've described previously, the only interface (most) web applications have is an HTML web GUI. The app should also have a programmatic API that can be invoked across the web via web services. In fact, the web GUI should be built upon the services. In practice, the web GUI probably won't use the web services APIs and instead will use something much more efficient such as simple/local or remote Java calls. Also, the web GUI may need access to services/functionality in the app that is not made publicly available via web services. Nevertheless, the idea is to apply the MVC approach to web apps, to separate the web GUI view from the app model; then the app model's services can be exposed as web services, so that Web 2.0 client apps can invoke the services programmatically.
In the August IBM WebSphere Developer Technical Journal
, there's a new article, "Deploying publish and subscribe applications into the Service Integration Bus
What's so interesting about this article? For one thing, it's by me and a co-author, Roland Barcia
. For another, it's on a rather interesting topic: How to do JMS publish/subscribe
messaging using the Service Integration Bus
in WAS 6
. So, check it out.
Web 2.0 is a new approach to how the World Wide Web should work: In addition to connecting users to enterprises via web browsers browsing web sites, client computers should also be able to connect to enterprise computers via web services.Web 2.0
is actually the third iteration of the web:
- Static web pages -- It's difficult to remember now, but the reason CERN originally developed the Cello web browser was so that any scientist with Internet access could view the results of particle collisions and decay from the center's particle accelerator. The pages contained both text descriptions of the experiments and pictures of the results. This was a huge step forward in making the data convenient to access.
The site hosting this blog, developerWorks, is mostly (entirely?) static; as are most corporate sites that are just trying to post info for their customers. These pages are like reading a newspaper or highway billboard: What you see is what the other guy viewing the same site sees, and what you see today is the same as what you saw yesterday (unless/until the web master has updated his content). Needless to say, these pages are viewed by humans.
- Dynamic web pages -- These too are viewed by humans, but the content changes depending on the time (without updates by the web master) and the viewer. They're not necessarily very interactive, but are created on demand: Your bank doesn't contain a static web page for every account that the web master updates daily; when you want to see your account, the bank's app creates a web page for you based on today's info. Dynamic pages can also be highly interactive, such as for e-commerce sites, and have effectively become an alternative GUI for applications.
Amazon and eBay (for example) are not merely web sites (in the static sense), they're applications hosted on and exposed as web sites and made accessible through web GUIs. It's gotten to the point now where calling a web GUI an alternative GUI for an application is a bit quaint; traditional thick clients that run outside of web browsers have become the alternative for web-hosted applications.
Likewise today, a client app can interface with a web site by parsing its HTML and invoking the proper URLs, but that's tedious and error-prone. (Interestingly, some web sites prevent you from interacting programmatically using a captcha, that technique where a human user must view and type in a sloppily rendered word that a computer can't read.) The client app needs the web-hosted app to have a programmatic interface. That's web services, and that's the Web 2.0.
So what good does a programmatic web API do you? A simple example is a travel agent app that must interface with the apps for airline, rental car, and hotel companies. The obvious way to do this is via the web, which we humans can do today via the companies' web sites, but which is still tedious and non-standard for a client app to do programmatically.
Taken to its logical extension, Web 2.0 will even change the way we humans use the web. Why does a particular web site have to look the way it does and work the way it does? Say you like Amazon's ability to browse books, but hate the way the web site looks, or hate the limitations of accessing the book catalog using a web browser. No problem. You can use a client app that runs in its own GUI (web browser, thick client, whatever), accesses the data Amazon makes available, and displays it to you the way the client app chooses specifically for you, not the way Amazon chose for everyone. Amazon in fact has web services available, AWS
, which enable you to this; so do eBay
Eventually, thanks to our web client apps, we'll start to lose the concept of web sites. Why should your client app show data from just one web site at a time? Why not have a personal finance app which shows you your bank accounts, mortgage, car loan, and stock portfolio all at once by accessing all those financial companies' web sites simultaneously?
It's the evolution of the information you need when you need it in the form you want it. TV channels mean a lot less with TiVo-style DVRs
. Radio stations mean a lot less with podcasting
. Web sites will mean a lot less with Web 2.0. It's the next iteration of the web.
Some links for more info on Web 2.0:
Also, as for the term "Web 2.0": It's the idea that's important, not the name. As D. Weinberger puts it
: "I haven't been a booster of the "Web 2.0" phrase because it sounded like something a conference organizer desperate for novely came up with." (I guess that desperate conference organizer would be O'Reilly!)
In a comment to ESB for Architects Article
, a reader asks: Could you clarify how to actually use DNS Endpoint Discovery, as advocated in the last paragraph, to find the right entry point with WAS 6 SIB?
I'll let James handle the DNS Endpoint Discovery part of the question, since he's the big advocate of that. In the meantime, see DNS Endpoint Discovery
, UDDI and DNS-EPD
, and More on DNS Endpoint Discovery
As for the SIB, and application doesn't really need to discover a bus instance. If you want an app to be able to access a bus instance, you deploy that app in an app server/cluster that is a bus member of that bus. Then the app simply has access to the bus by using a JMS connection factory configured for that bus. See pub/sub in the SIB
article and "Deploying message-driven beans and JMS applications into the Service Integration Bus
."Service Integration Bus
There's still the issue of "how does the app know what queues are available?" In JMS, this is hard coded through resource references
and JNDI bindings
. However, I believe apps will need to be able to bind to these resources more dynamically; see ESB vs. Message Bus
. I envision an ESB with a UDDI-like service; an app wanting to invoke a service passes its description (WSDL, perhaps) into the ESB's UDDI, which returns the bindings for the JMS/messaging channels for invoking the service. The app then uses those channels to make the request and receive the response. How would you find the ESB and its UDDI service? For that, you might need DNS Endpoint Discovery, or you might be able to just use pre-configured connection factory.
This probably isn't any new info, but let's make sure we're on the same page here, especially since I haven't seen this discussed extensively anywhere; it's just assumed. The way you implement a service in J2EE is with a stateless-session bean.
A stateless session bean
(SSB) is a kind of EJB
that manages a user's access to an app's domain model
. As an EJB, an SSB manages overhead issues like sharing of instances, thread reuse, transactions, and security; this lets the SSB developer focus on implementing code for business logic. Because an SSB is stateless, a user only cares about using an instance from a pool of the same type; since all instances are the same, which one a particular user gets makes no difference.
For example, a banking SSB might have methods like
. Each method is stateless, so it needs appropriate arguments like account IDs and payment info.
Services are also considered stateless; all state must be passed in as parameters. Web services are stateless, HTTP itself is a stateless transport.
So in J2EE, it makes sense to implement a service, such as a web service, as an SSB. If the service transport is HTTP, it's easy to add access to an SSB by implementing a service activator (EIP
), which in J2EE for HTTP is a servlet
. If the transport is JMS
, use the service activator pattern again, but this time implement it as an MDB
. A J2EE 1.4 container can expose an SSB as a JAX-RPC web service directly
; the container acts as the servlet.
Part of the beauty of implementing a service as an SSB is that clients then have great flexibility to invoke it synchronously or asynchronously. I've already discussed asynchronous access using service activators for HTTP or JMS transports. Java clients of the service may wish to invoke the service synchronously, which is easy to do with an SSB--just use its local or remote home and interface. So SSBs make service invocation very flexible.
Some people don't like EJBs. Perhaps they're not using Java, they're using .NET; they'll use .NET's equivalent of an SSB. Perhaps they're using Java but not J2EE, or at least not EJBs. This principle still applies, they would just use a JavaBean
. But that J2SE object would need to handle security, transactions, remoteness, pooling--pretty soon, you've reinvented EJBs, so you should just use EJBs to begin with.
So an SSB isn't the only way to implement a service in Java, but if you want to take advantage of J2EE, then an SSB is a good way to go.
Web services are generally thought of as SOAP over HTTP. Another approach is XML-RPC.XML-RPC
is an alternate web services technology, a simple technique for invoking an application's method or procedure by sending XML documents in HTTP packets. Sound kind of like SOAP? Well, XML-RPC is the predecessor of SOAP. Apparently Microsoft thought XML-RPC was too simple, added more functionality, and gave the more complex technology the perhaps misleading name/description: Simple Object Access Protocol (SOAP).
XML-RPC has gone out of favor. People seem to prefer either SOAP
For more info:
has released a new tool, the Performance Harness for Java Message Service
From the description:
It provides a complete set of JMS functionality as well as many other features such as throttled operation (a fixed rate and/or number of messages), multiple destinations, live performance reporting, JNDI, and multiple vendor plug-ins.
The author, Marc Carter, is on the WebSphere MQ
development team and wrote the performance harness to analyze WMQ. He has also authored the JMS Performance with WebSphere MQ for Windows V6.0
and JMS Performance with WebSphere MQ V5.3 on Windows 2000
It's been awhile (since June/July
(PDF), actually), but the August edition of the IBM WebSphere Developer Technical Journal
is now online.
In The EJB Advocate
, Geoff Hambrick documents a discussion he had with some really smart young fellow about where to implement the code for producing DTOs. Scott Johnson talks about how to be a happy programmer
. Roland Barcia is this month's Meet the Experts on developing apps on RAD 6
Scott Simmons introduces the WebSphere Integration Reference Architecture
, which among other things shows how an ESB fits into your apps. Several of my fellow ISSWers have an article on advanced authentication in WAS
(they're in favor of it!). Rachel and Andre continue their building an ESB
series, and there's an article on custom portal code performance
And there's an article on doing pub/sub in the SIB that I'll talk about next.
I've talked about the REST
approach for web services. Does REST work with WSDL?
Individual web services are typically described with Web Services Description Language
(WSDL) documents. WSDL describes a web service in four parts:
- Port type -- The service and its ports/operations
- Messages -- The format of the requests and responses
- Types -- Custom data types beyond the standard primitives defined by the WSDL spec
- Bindings -- The address of the host providing the service
WSDL is independent of SOAP
, but closely related to it, since the request and response messages are usually assumed to be formatted as SOAP.
So do WSDL and REST get along? Some say sure, some say "no way," and others say "why bother?" It seems to depend on how deeply you drink the Kool-Aid
on REST. Seems to me that the port type section doesn't do much for REST, since the operations are always GET, PUT, POST, and DELETE. The port type would just specify which of those four verbs are supported. The bindings section might be useful for finding the hosts of REST services, but that pre-supposes those services are described by WSDL and can be looked up in something like UDDI
Which leaves the messages and types sections of WSDL. Here there's a fair bit of disagreement between the SOAP and REST philosophies. SOAP is more strongly-typed, saying "Here's the format; take it or leave it." REST is looser; a single service might support multiple formats; the client and host negotiate which format to use for each transaction. The REST message formats are assumed to be XML, but even that's an implementation decision. The SOAP body is an XML document (specifically, the root element). So SOAP and REST agree on XML, but SOAP specifies only one XML schema whereas a REST service may support many. WSDL for a REST service would specify only one XML schema, therefore limiting its flexibility.
So, does a REST service even need the flexibility to support multiple XML schemas? If it can settle on one request/response format pair for a particular operation (GET, PUT, or POST; DELETE doesn't need data), then it seems to me that the REST service can be described with WSDL.
As I've discussed previously, the Web 2.0 approach
gives Web apps a Web services API so that the app's functionality can be invoked programmatically. Which then raises the question: What's a Web service?
In the Web 2.0 sense, a Web service is just some technology for invoking an application's service across the Web. The most common approach today is SOAP
. However, many people believe that SOAP is too complex; they tend to prefer REST
instead. Some diehards still use XML-RPC
, the predecessor to SOAP which also came before REST. Amazon's AWS supports
both SOAP and REST.
Wikipedia's list of Web service markup languages
(which I updated
) lists these and others, such as BEEP
. It also lists a bunch of related XML schemas used with Web services that aren't actually for invoking Web services, like WSDL
(for describing interfaces), UDDI
(for locating service providers), and BPEL
(for programming sequences of service invocations).
The point is, when I talk about Web 2.0 and giving Web apps a services API, not just an HTML GUI, I'm using the term "Web services" loosely to mean programatically invoking an application's service across the Web
. (Google has a similar definition
.) The format may be SOAP or just XML-RPC. The whole approach could be REST, which is more format independent. The transport is presumably HTTP, because that's what the Web runs on today, but perhaps even that will change someday.
The important trend of Web 2.0 is Web applications making their services available for direct, programatic invocation. The technology may change over time, but the need will probably only grow.