« Return to Thread: Our REST implementation

Re: Our REST implementation

by Matthew Ratzloff :: Rate this Message:

This morning I looked at Zend_Rest for the first time and was surprised to see just how un-RESTful it is! I looked at the mailing list archives to see if I could find any design discussion and found this thread, so I'm resurrecting it to get other people's opinions.

The component really is more RPC than REST, I think. And since these two concepts are basically diametrically opposed, it seems like the "Zend_Rest" name is misleading. Furthermore, while comparing this to Zend_XmlRpc I didn't see much in the way of substantive differences.

Without intending to sound harsh, what is the niche that this component fills that wouldn't be more appropriately solved with XML-RPC or a fully REST-compliant architecture?

-Matt

Shahar Evron wrote:

I am not an expert on the subject, but I think the key difference
between REST and RPC based web services is more philosophical:

RPC (Remote Procedure Call), as the name suggests, is procedure focused,
as SOAP and XMLRPC are. In practice, an RPC web serivce will usually
present numerous procedures (or methods) than can be executed on a
single resource (URL).

REST (Representational State Transfer) on the other hand focuses on
resources ("nouns") and allows several methods (usually CRUD like
methods) to be executed on each resource. In the web services world,
that would usually mean you have numerous resources (URLs, "nouns"), and
you can execute a limited number of "methods" ("verbs") on each one
(HTTP GET, PUT, POST, DELETE == CRUD).

A service which, for example, allows a user to retrieve, add, update and
delete articles in a blog, would be designed this way:

RPC:
POST http://example.com/blog/soap/articleManager.php
(Call the same URL, while the SOAP request body defines the method and
parameters)

REST:
GET http://example.com/blog/rest/articles - get list of all articles
PUT http://example.com/blog/rest/articles - create a new article
GET http://example.com/blog/rest/articles/1 - retrieve article #1
POST http://example.com/blog/rest/articles/1 - update article #1
DELETE http://example.com/blog/rest/articles/1 - delete article #1

and so on. One might simply say that REST takes a different approach to
mapping URLs to objects / methods / parameters, but I guess that under
some circumstances there is more than that.

There is something very appealing for HTTP freaks in REST I think
because of the proper use of request methods (GET is never state
changing while POST is, etc.).

As I mentioned briefly earlier, I think it would be quite easy to
implement a Rest_Server component (even if we name it differently) as
some kind of subclass of some Zend_Controller modules - it looks like
the REST URL to object / method / parameter mapping can be done quite
easily with some smart Zend_Controller routing / dispatching rules or
plug-ins.

Shahar.

On Tue, 2007-05-29 at 15:55 +0200, till wrote:
> Shahar,
>
> On 5/28/07, Shahar Evorn <shahar.e@zend.com> wrote:
> > I did some more reading on this and it really does seem that our
> > Rest_Server is more RPC oriented (eg. method focused and not resource
> > focused) web service implementation.
>
> I had this discussion with a friend a while ago. I am not sure where
> we left of - so can you provide an example where REST is less RPC and
> more like ... whatever it is supposed to be? ;-))
>
>
> Cheers,
> Till

« Return to Thread: Our REST implementation