axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From V D <>
Subject What is REST
Date Sat, 01 Jul 2006 15:01:41 GMT

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

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:
For additional commands, e-mail:

View raw message