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.
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.
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.
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.
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.
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.
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.
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
