aspose file tools*
The moose likes Web Services and the fly likes REST, XML over HTTP, Web Services? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Web Services
Bookmark "REST, XML over HTTP, Web Services?" Watch "REST, XML over HTTP, Web Services?" New topic
Author

REST, XML over HTTP, Web Services?

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
What exactly is REST???

Isn't it sending XML over HTTP?

How different it is from Web Services or XML over HTTP?

Please point me some good links, I couldn't find myself.

Thanks.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
As is so often the case, the FAQ page has the answer. There are several relevant links about REST in the http://faq.javaranch.com/java/WebServicesFaq


Ping & DNS - my free Android networking tools app
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by ankur rathi:
What exactly is REST??? Isn't it sending XML over HTTP?


Most definitely not. Though it is a common misconception that "XML over HTTP" is REST.

REST requires that you organize your design around "resources", each of which has its own URI. Then you use the standard HTTP methods to obtain or manipulate the "state" of those resources. This is accomplished through the exchange of "representations". The "representations" can be in an XML format but they don't have to be - as a matter of fact the same resource may be capable of "representing its state" in multiple formats and give you the preferred format that you specified in the Accept HTTP header.

SOAP is ignorant of the transport protocol that is moving it; that way it can still work even if it isn't going over HTTP. REST on the other hand simply accepts that "web services" use HTTP and the web. So the HTTP protocol is embraced; the only operations (on the resources) supported by a RESTful web service are the HTTP methods: PUT, GET, POST, DELETE, HEAD, etc.; errors are reported through HTTP status codes (instead of e.g. SOAP faults).

Many "XML over HTTP" setups are simply customized versions of XML-RPC.

You should still have a look at the resources listed under the Web Services FAQ What is Rest? entry.
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by Peer Reynders:



REST requires that you organize your design around "resources", each of which has its own URI. Then you use the standard HTTP methods to obtain or manipulate the "state" of those resources. This is accomplished through the exchange of "representations". The "representations" can be in an XML format but they don't have to be - as a matter of fact the same resource may be capable of "representing its state" in multiple formats and give you the preferred format that you specified in the Accept HTTP header.



Thanks!

State of the resource - what is it? Say, I have an image on server which is a resource, what states it cab be in???
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12803
    
    5
State of the resource - what is it? Say, I have an image on server which is a resource, what states it cab be in???


All the possible images - a very large number indeed.

This article includes a link to Fielding's original dissertation and some other cool articles.

Bill
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by ankur rathi:
State of the resource - what is it? Say, I have an image on server which is a resource, what states it cab be in???


Example: The cover of the book Refactoring Databases shows the Burlington Bay James N. Allen Skyway - that bridge happens to have a number of traffic cameras over it. This URI

http://www.mto.gov.on.ca/english/traveller/compass/camera/pictures/BurlCamera/loc05.jpg

identifies a resource that is equivalent to one of them. The image is updated every 3-5 minutes. So in essence the (camera) resource identified by that URI changes its state approximately every 4 minutes and the representation of that state is an image stored in the JPEG format.

Also Fielding talks about "Hypermedia as the engine of application state". Basically a resource representation can contain links to other resources - through the links the resources become connected and the application's (client) state is created by the path that the application (client) takes through the linked resources.

Tim Ewald: I finally get REST. Wow.
[ November 15, 2007: Message edited by: Peer Reynders ]
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by William Brogden:


All the possible images - a very large number indeed.

Bill


Okay, but they are different resources not the different states of a resource.
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by Peer Reynders:

So in essence the (camera) resource identified by that URI changes its state approximately every 4 minutes and the representation of that state is an image stored in the JPEG format.


That make sense but what is so special about it? I mean, it's the state of camera and not the state of image...

How different it (REST) is from sending image over http (<img src="a.jpg" /> in the sense of implementation???

Thanks.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 42264
    
  64
Originally posted by ankur rathi:
Okay, but they are different resources not the different states of a resource.

The resource here is the camera, not the image.

How different it (REST) is from sending image over http (<img src="a.jpg" />) in the sense of implementation???


HTML markup is (for the most part) meant for a browser, and thus human consumption. A better comparison is with the SOAP stack. REST offers a simpler model of addressing and accessing resources, which has less overhead (and less functionality). In this case -where the resource is public, and no changes to it are possible- this is more than adequate.
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12803
    
    5
Okay, but they are different resources not the different states of a resource.


The URI defines a resource - the data at the other end can change.

That is the whole point of REST - admittedly hard to grasp if you are used to thinking the other way around. See that Tim Ewald blog that Peer cites above.

Bill
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by ankur rathi:
Okay, but they are different resources not the different states of a resource.


Originally posted by Ulf Dittmer:
The resource here is the camera, not the image.


... and the image is a representation of that (camera) resource's current state!

Burton sees the future of SOA and it is REST
Anne Thomas Manes: Roy Fielding on REST
JSR 311: JAX-RS: The Java� API for RESTful Web Services
[ November 16, 2007: Message edited by: Peer Reynders ]
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by William Brogden:


The URI defines a resource - the data at the other end can change.

That is the whole point of REST - admittedly hard to grasp if you are used to thinking the other way around. See that Tim Ewald blog that Peer cites above.

Bill


URI is same all the time but different-different resource might come up to the client (in other word, a different state).

For example:

http://www.mto.gov.on.ca/english/traveller/compass/camera/pictures/BurlCamera/loc05.jpg

This URI might show different image each time when we access it. Is it???

Someone is updating the pic. What's REST in it?

William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12803
    
    5
Someone is updating the pic. What's REST in it?


That is one of the main points, REST does not care about underlying processes, it only cares about the current state of the resource.

Have you read the articles and commentary we have been pointing you to?

Bill
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by ankur rathi:
URI is same all the time but different-different resource might come up to the client (in other word, a different state).


Incorrect - the conceptualized camera is the resource - the image(s) are not resources - they are representations of the resource's state.

  • one particular camera -> one particular resource
  • URI - acts as the (addressable) identifier for the resource. It is preferable that a resource should only have one unique URI. Exposing multiple URIs for the same resource leads to dilution - different looking URIs refer to the same resource - in that case one of the URIs needs to be the canonical URI and ideally all the other URIs should redirect to the canonical URI. In some cases each representation of a resource can have its own URI. A press release can be a resource. That resource can be represented in multiple languages and each representation could have its own addressable URI e.g. "http://www.mycompany.com/press/2007-11-19.eng" and "http://www.mycompany.com/press/2007-11-19.hin". The "press release" resource can still be identified by the platonic form "http://www.mycompany.com/press/2007-11-19" - however when you use this URI as an address you should be served the representation that is most appropriate according to the language specified in the Accept-Language header in your HTTP request.
  • representation - the format in which the state of the resource will be sent to you. Some resources have multiple representations. In this case there is only one - the image/jpeg media-type.
  • state - the information conveyed through the representation. In most cases HTTP-POST is used to update the state of an existing resource identified by a particular URI. In this case, from your perspective, the resource is a read-only resource, so you can only read the current state (the current collection of bits that the JPEG image is comprised of) of the resource. However something else is updating the state of that resource regularly.


  • With this particular URI you see the .jpg extension and think "image". However an image can be served from an URI that doesn't end in a filename (with an extension). The browser or any other HTTP client uses the Content-Type HTTP response header (image/jpeg) to figure out that a JPEG image is being sent.
    ankur rathi
    Ranch Hand

    Joined: Oct 11, 2004
    Posts: 3830


    Client access a.html resource, client is in a state. Client can traverse either to b.html or c.html. In either case, the state of the client will change... and it will keep on changing as client accesses resources.

    William, I am reading but not understanding much.
    William Brogden
    Author and all-around good cowpoke
    Rancher

    Joined: Mar 22, 2000
    Posts: 12803
        
        5
    In either case, the state of the client will change... and it will keep on changing as client accesses resources.


    But the RESTful service does not care what state the client is in. This is what keeps REST services simple, it just recognizes the fact that the HTTP request / response cycle is naturally stateless. The programmer can create a system that pays attention to client state but that is on top of the basic request / response cycle.

    Bill
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Originally posted by ankur rathi:
    I am reading but not understanding much.


    In the context of this particular issue reading CHAPTER 4: The Resource-Oriented Architecture - Application State Versus Resource State page 90 of the book, page 15 of the PDF might help. (The entire chapter might be a good idea).
    Cameron Wallace McKenzie
    author and cow tipper
    Saloon Keeper

    Joined: Aug 26, 2006
    Posts: 4968
        
        1

    God, I love these types of discussions.

    -Cameron McKenzie
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: REST, XML over HTTP, Web Services?