V D,
Please keep in mind that Wikipedia is not necessarily the source of
universal truth.
As a starting point for studying the REST architecture, I suggest the
RestWiki:
http://rest.blueoxen.net/cgi-bin/wiki.pl
Of course, the primary source of truth about REST is Roy Fielding's
dissertation, which normally can be found at
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm, but for
some reason today, I'm getting a 403 Forbidden error on that link.
REST is an architectural style in which the core unit of design is a
resource. Every resource has a unique identifier (a URL). Components
communicate by exchanging representations of the resource rather than
by directly performing operations on the resource. Each resource
exposes a uniform set of methods for exchanging representations -- for
example (from HTTP), GET, PUT, POST, DELETE. (REST doesn't require use
of HTTP, but HTTP is inherently RESTful.) All interactions with the
resource are stateless.
This approach is fundamentally different from an architectural style
in which the core unit of design is a service (SOA).
Let me provide an example. Let's say that you want to build a system
that allows users to manipulate lightbulbs.
In SOA, the core unit of the design is a service which exposes some
capability (managing lightbulbs). A service exposes that capability
through a set of operations:
- locateLightbulbs
- input (query parameters)
- output (array of lightbulb identifiers that match the query
parameters)
- queryLightbulbs
- input (array of lightbulb idenitifers)
- output (array of lightbulb idenitfiers and their states --
on/off/luminosity setting)
- setLightbulbs
- input (array of lightbulb identifiers and state settings)
- output (void or confirmation/fault)
In REST, the core unit of the design is the resource that you want to
manipulate (the lightbulb). Each manageable lightbulb is a unique
resource and has a unique URL. You manipulate the resource by
exchanging representations of it.
- GET retrieves its state
- PUT sets its state
- POST adds additional state, such as its location and its wattage.
Notice the differences in the design. In the service-oriented
approach, you manage all lightbulbs through one service. The service
has a unique endpoint URL, but each lightbulb does not. The service
encapsulates the actual resources. You manipulate a lightbulb by
invoking an operation that is specific to this service (i.e., not a
uniform API). You identify the lightbulb(s) that you want to query or
set as part of the content of the invocation message.
In the resource-oriented approach, you don't have a central service.
Each lightbulb has a unique URL, and you manipulate the lightbulb
using a uniform interface.
More comments inline below...
On 7/1/06, V D <[EMAIL PROTECTED]> wrote:
I tried to ignore this REST term for a while. But it keeps come up, so
I take a plunge and check it out. Yes, people often refer it to
http://en.wikipedia.org/wiki/Representational_State_Transfer
So, I check it out.
My first impression: it's non-sense. My deeper impression, it's nothing
more than a catch phrase. Yes, for those who bought into this
term/architecture may get offended, but let me explain.
You probably won't offend people. They'll just assume that either:
a) you haven't spent enough time studying REST to understand it
or
b) you're too thick to understand it
REST is not nonsense, and it's way more than a catch phrase. It's just
that it's a very different way to design systems. If you don't spend
the time to grok it, you won't understand it.
First, the term REST, a noun to me because it IS an architecture name.
Then why would RESTful? it sounds like REST is adjective. A catch
phrase.
REST is a noun -- an architectural style.
RESTful is an adjective applied to an application or system that
complies with the REST architectural style.
What's a catch phase other than a shorthand way to reference
something? REST is as much a catch phrase as SOA is. That doesn't mean
that the term doesn't have a true meaning.
Second, reading the page, it is recognized that REST is very broad. So,
using this page alone, there is no way I cannot develop a system that
communicate with others in a standard way. Communication without
standard? It's not communication. For example, wikipedia compare REST
to RPC. RPC is not a standard. You cannot say, let's program it in RPC
and we connect to each other.
As I said at the beginning, Wikipedia is not necessarily the source of
all truth. Obviously, in this situation, it doesn't provide enough
information to be useful to you.
It's inappropriate to directly compare REST with RPC. It's also
inappropriate to directly compare REST with SOAP. (It's more
appropriate to compare RPC or SOAP with HTTP. It's also more
appropriate to compare REST with SOA.) REST is not a communication
technology; it is an approach to designing systems. RPC is a
communication technology for invoking operations. You typically would
not use RPC in a RESTful system because RPC is designed to invoke
methods, not to exchange resource representations.
Third, principle. This things based on stateless, client/server
protocol. With a big exception that the web is not just stateless.
Taking the "stateful" out of the web, you cut most of its usefulness.
Without cookies and url re-write, there's no commercial app on the web.
Yes, you can do something else like cookies, like submit something to
make it like cookie, but cookie is not the point, the point is
stateful. "stateful" is good. Repeat that 10 times.
Use of cookies does not imply "stateful". In fact, cookies enable you
to make what would normally be a stateful interaction stateless.
Stateful implies that the server maintains active (non-saved) state
about your specific session between two interactions, and if for some
reason your session terminates, all your state goes away, and you have
to start your process over. If you use a cookie rather than
maintaining state, then you can always resume your interaction just
where you left off by providing a reference to saved state (the
cookie).
Haven't you ever had an experience on the web where you hit the back
button, and the server says that it can't take you back -- instead you
must resubmit and refresh the screen? That's stateful. And it's
definitely not RESTful.
The 2nd principle, well-defined operations. Take the web for example:
post, get, put, delete. How is this different from SOAP? They even use
less operation. Get/Post all the time (this may be not accurate, but
the point is that they also use the web's limited, well-defined
operations). But that's not enough, so they build on top of its any
operations needed. This is so that people can do things differently on
it. So, one can argue that REST does not need that and can handle the
job. Let's see. With REST, can one update a shopping card? No, you
can only do a GET/PUT/POST/DELETE? Sure, you can update a shopping card
using REST. They use one of the operation above, but I am sure they use
some way (through url?) to signal the update of the shopping card. How
is this different from SOAP over web? Nothing with respect to the
well-defined operations. Same basic web operations, with some way to
signify a higher level of operation. The difference is in how that
higher level of operation is defined. Whether in the header (or url),
in the body, what format, etc.
You need to understand the basic concepts of REST for this to make
sense to you. REST is *resource* oriented rather than *service*
oriented. SOAP (typically) is service oriented rather than resource
oriented, although you can use SOAP in RESTful applications.
Resources are things (nouns). Services expose a set of capabilities
that can perform operations (verbs) on things.
In a typical SOAP application, a service exposes a set of operations
which are unique to the service (i.e., it does not expose a uniform
interface). An inbound SOAP message conveys a request to invoke one of
those operations, which, in Axis, translates into a method invocation
on a Java object. Very few people use SOAP to exchange representations
of resources.
The 3rd principle, universal syntax. The same URL mechanism is used to
access resource. How is it different from SOAP of accessing a web
service end point? Look up and things like that is only required if you
don't have the URL. One can argue that they are not different, but that
is the principle. But what make this principle unique? People have a
standard on IP/port to communicate in TCP/IP. They have standard (at
least in the US) on snail mail address to get/send mail to someone. One
thing I can see that SOAP may have 1 end point, but different operation
may give you different meaning, different resource. This is another way
to put another abstract level above the URL. So, my interpretation is
that REST use different URL for different resources, and different
operations. While SOAP has a single end point, the depend on the
request, they can get different resource, or issue different command. I
think SOAP is better. This concept is like package in Java, or
namespace in general. You have [endpoint,operations] in SOAP or
endpoint_operations in REST. One can argue that SOAP does not have a
standard on the operations. This is the beauty of it. There's millions
of different apps out there, who know what operations to defined. If
REST forces you to 5 operations for example (this is not the case), what
good is it? Otherwise, if it defines millions of operations using the
same way to represent operation (URL), but the meaning of each operation
is depend on whoever make it defined it, then there's no relevant
difference with SOAP here.
Again, you need to grok the core principles of REST for this to make
sense.
In REST, each resource has a unique URL, and the only things you
*need* to be able to are:
- get its state (GET)
- update its state (PUT)
- add additional state (POST)
- delete its state (DELETE)
With SOAP, you don't expose each individual resource, you expose a set
of operations that can operate on some arbitrary set of resources. The
resources are encapsulated by the service and its operations. It's a
fundamentally different design approach.
The 4th principle, the use of hypermedia. The idea here is links inside
content. I don't see how SOAP cannot send links in its content which is
also XML. With SOAP, the links is not universally defined like the <a>
tag in HTML. However, the idea here is not about how to define the tag,
but way to link from one point to another.
It is not just about links inside content. It's about the fact that
each resource is a first-class Web resource with its own URL, and it
can be linked to, retrieved, cached, etc.
So, there you go. If you don't know REST, you can check the link on top
(or other resource). Read my comment (optional of course) and get your
own opinion on it. To me, it's just a catch phrase. However, its use
maybe important and widespread. The point is that if I coin WEB as
"ASDF", then "ASDF" is as important and and widespread, but what
significance is in the new name?
I suggest you take another look and try to think outside the box this
time. REST is fundamentally different.
Anne
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
