REST is not about URIs! REST is one solution to the SAME problem as SOAP or XML-RPC. It's the general problem of a network based application architecture, there all just different approaches.
My understanding of REST, as far as URIs go, is that a URI should not be composed of elements relating to a resources location on a server, time, or user session info, but to an unchanging unique identifier that is recognisable to humans. This does not mean REST promotes good looking URIs. What it means is that in a network based application other entities will want to gain access to that resource for various purposes (one is to GET it). Now all of the entities are written by human beings and in the REST view of the world (a resource centric view) a human being should be able to write a process to GET a resource and be assured that the URI to it will not change.
Compare this to the SOAP/XML-RPC view of the world which is process centric where the human would write a program to request from a central point access to a method (passing optional args) to GET the resource for them.
So, for example:
a SOAP/XML-RPC style app might have a URL to send a HTTP POST containing a XML envelope with the name of the method: "getBolt" and send it the manufacturers catalog ID for the bolt: "12345C".
A REST application would instead have you make a HTTP GET request to a URI for the bolt: manufacturer.com/bolts/12345C
The point about REST URIs is that they make sense to humans. In the example a catalogue ID is perfectly sound.
However, a Lotus Notes document UNID is completely contrived and does not help anyone in a REST style network application.
SOAP/XML-RPC style architectures are more familiar to programmers because using them is akin to making API calls, and so it's easier to understand. REST uses standard HTTP requests but its capabilities are no less. If I wanted to update the bolt's info I'd POST to it, if I wanted to delete it I'd send a HTTP DELETE request.
Regarding the contruction of URIs in any web application your example of a long one is completely rediculous and no one here is advocating that.
You say users never interact with URIs?
- Try authoring a webpage/web app where you need the URIs to resources: readable/understandable URIs reduce errors and make it easier to work with them
- When you email a link to a friend (Try emailing a URI from a websphere portal page).
- Those email banking scams which trick people to click a link - they work because people read and trust what is in the address bar!
- Try reading this discussion board and make sense when people post something like: "Hey I read this great article here: someblog.com/articles/x34gr5t", now you might get a sense of its relevance from the discussion context but otherwise you wouldn't know if it's worthwhile to visit. If it said "someblog.com/articles/all_about_cheese" you'd have a much better idea. This = usability. Actually this is a totally redundant example because Jake turns all links into '{link}', shame on you Jake! But you get the idea.
- I use URIs all the time and it drives me nuts when they are unreadable.
- The address bar is like a backup command line interface : when no other option is available it's great when you know you can type in 'company.com/bolts/bolt catalog #' and get what you want.
Stan, you're thinking with blinkers on man!
REST is not about URIs! REST is one solution to the SAME problem as SOAP or XML-RPC. It's the general problem of a network based application architecture, there all just different approaches.
My understanding of REST, as far as URIs go, is that a URI should not be composed of elements relating to a resources location on a server, time, or user session info, but to an unchanging unique identifier that is recognisable to humans. This does not mean REST promotes good looking URIs. What it means is that in a network based application other entities will want to gain access to that resource for various purposes (one is to GET it). Now all of the entities are written by human beings and in the REST view of the world (a resource centric view) a human being should be able to write a process to GET a resource and be assured that the URI to it will not change.
Compare this to the SOAP/XML-RPC view of the world which is process centric where the human would write a program to request from a central point access to a method (passing optional args) to GET the resource for them.
So, for example:
a SOAP/XML-RPC style app might have a URL to send a HTTP POST containing a XML envelope with the name of the method: "getBolt" and send it the manufacturers catalog ID for the bolt: "12345C".
A REST application would instead have you make a HTTP GET request to a URI for the bolt: manufacturer.com/bolts/12345C
The point about REST URIs is that they make sense to humans. In the example a catalogue ID is perfectly sound.
However, a Lotus Notes document UNID is completely contrived and does not help anyone in a REST style network application.
SOAP/XML-RPC style architectures are more familiar to programmers because using them is akin to making API calls, and so it's easier to understand. REST uses standard HTTP requests but its capabilities are no less. If I wanted to update the bolt's info I'd POST to it, if I wanted to delete it I'd send a HTTP DELETE request.
Regarding the contruction of URIs in any web application your example of a long one is completely rediculous and no one here is advocating that.
You say users never interact with URIs?
- Try authoring a webpage/web app where you need the URIs to resources: readable/understandable URIs reduce errors and make it easier to work with them
- When you email a link to a friend (Try emailing a URI from a websphere portal page).
- Those email banking scams which trick people to click a link - they work because people read and trust what is in the address bar!
- Try reading this discussion board and make sense when people post something like: "Hey I read this great article here: someblog.com/articles/x34gr5t", now you might get a sense of its relevance from the discussion context but otherwise you wouldn't know if it's worthwhile to visit. If it said "someblog.com/articles/all_about_cheese" you'd have a much better idea. This = usability. Actually this is a totally redundant example because Jake turns all links into '{link}', shame on you Jake! But you get the idea.
- I use URIs all the time and it drives me nuts when they are unreadable.
- The address bar is like a backup command line interface : when no other option is available it's great when you know you can type in 'company.com/bolts/bolt catalog #' and get what you want.