Let's take a simple web service as an example: querying a phonebook application for the details of a given user. All we have is the user's ID.
Using Web Services and SOAP, the request would look something like this:
<?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body pb="http://www.acme.com/phonebook"> <pb:GetUserDetails> <pb:UserID>12345</pb:UserID> </pb:GetUserDetails> </soap:Body> </soap:Envelope>
(The details are not important; this is just an example.) The entire shebang now has to be sent (using an HTTP POST request) to the server. The result is probably an XML file, but it will be embedded, as the "payload", inside a SOAP response envelope.
And with REST? The query will probably look like this:
http://www.acme.com/phonebook/UserDetails/12345
Note that this isn't the request body -- it's just a URL. This URL is sent to the server using a simpler GET request, and the HTTP reply is the raw result data -- not embedded inside anything, just the data you need in a way you can directly use.
- It's easy to see why Web Services are often used with libraries that create the SOAP/HTTP request and send it over, and then parse the SOAP response.
- With REST, a simple network connection is all you need. You can even test the API directly, using your browser.
- Still, REST libraries (for simplifying things) do exist, and we will discuss some of these later.
Note how the URL's "method" part is not called "GetUserDetails", but simply "UserDetails". It is a common convention in REST design to use nouns rather than verbs to denote simple resources.
The letter analogy
A nice analogy for REST vs. SOAP is mailing a letter: with SOAP, you're using an envelope; with REST, it's a postcard. Postcards are easier to handle (by the receiver), waste less paper (i.e., consume less bandwidth), and have a short content. (Of course, REST requests aren't really limited in length, esp. if they use POST rather than GET.)
4 comments:
thanks for a great article.
So even a query needs to be sent to a server via a HTTP POST? Why is that? Why is it not using a GET?
GET's are not supposed to have any side effects. Why is that not appropriate to use here?
Not at all -- with REST, queries are normally send using GET. You can use POST, but you rarely have to (e.g., for requests which contain a large amount of data, such as detailed form submissions.)
Hello Dr
In this example, where is method UserDetails located?
http://www.acme.com/phonebook/UserDetails
1)http://www.acme.com/phonebook/ is the directory
2)UserDetails is the method...but where is this method located? if it exists in (for example) the java file Test.java then how can i construct the URL? is it going to be:
http://www.acme.com/phonebook/Test/UserDetails?
please help me out with this because it's a little bit confusing to me...thank you
Most web development languages are geared towards the path?query URL format (e.g., http://www.acme.com/phonebook/UserDetails?id=12345). And in most cases, the easiest way to support cleaner, more elegant URLs (like .../UserDetails/12345) is by URL rewriting. The trick is to configure your web server (e.g., Apache httpd) to internally process any request formatted in one way (.../UserDetails/12345) as if it was formatted in another way (.../UserDetails?id=12345). The rewriting translation from one format to the other is normally a trivial regular-expression conversion.
Post a Comment