Our REST implementation

[Shahar Evron]

Hi all,

I had the chance to listen to Ben Ramsey's talk about REST last week in
IPC07. During the talk, Ben explained the REST model / philosophy, and
mentioned that our Zend Framework implementation of Zend_Rest_Server is
in fact not RESTFul, but more RPC style.

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 was going to propose a redesign of our REST server, which will be
similar to a front controller router / dispatcher implementation,
mapping URLs to classes which contain a method / action for each HTTP
"verb" (GET, POST, PUT, DELETE). I think this could be a base for a
simple, light and elegant implementation.

Before I do that, I would like to hear your opinions about this, as I am
not too experienced with REST and I have a general feeling that there is
no real "standard" we can follow here.

Shahar.

[Davey Shafik-3]

This isn't quite true, and I spoke to Ben about this too.

The point of Zend_Rest_Server is to help mapping
requests to *existing* (read: used elsewhere) code. Or at least
code consistent with a project.

The Zend_Rest_Server should *not* be modified, but I have
no problems with building something *on top* that is more RESTy.

But in all honesty, REST is about making requests and getting responses,
those responses have to be generated somehow, so its RPC, no matter how
it happens.

The point of Zend_Rest_Server is that Zend_Rest_Client can automate
those REST calls
using a programmatic local API.

- Davey

Shahar Evorn wrote:

> Hi all,
>
> I had the chance to listen to Ben Ramsey's talk about REST last week in
> IPC07. During the talk, Ben explained the REST model / philosophy, and
> mentioned that our Zend Framework implementation of Zend_Rest_Server is
> in fact not RESTFul, but more RPC style.
>
> 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 was going to propose a redesign of our REST server, which will be
> similar to a front controller router / dispatcher implementation,
> mapping URLs to classes which contain a method / action for each HTTP
> "verb" (GET, POST, PUT, DELETE). I think this could be a base for a
> simple, light and elegant implementation.
>
> Before I do that, I would like to hear your opinions about this, as I am
> not too experienced with REST and I have a general feeling that there is
> no real "standard" we can follow here.
>
> Shahar.
>
>  

[tfk]

Shahar,

On 5/28/07, Shahar Evorn <shahar.e@...> 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

[Matthew Weier O'Phinney-3]

-- till <klimpong@...> wrote
(on Tuesday, 29 May 2007, 03:55 PM +0200):
> On 5/28/07, Shahar Evorn <shahar.e@...> 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? ;-))

Well, there's always the dissertation that started it all:

    http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

Note particularly Chapter 5, which describes the REST implementation.

I've also found the following to be a good description of REST:

    http://www.xfront.com/REST-Web-Services.html

The difference between a classic REST implementation and traditional RPC
services is that REST is very resource centric, and uses the HTTP
request itself as the verb: i.e., GET, POST, DELETE, PUT. As an example,
instead of something like:

    http://example.com/rest?method=foo¶m1=bar¶m2=baz

which might invoke the 'foo' method on the remote server with the
parameters 'bar' and 'baz', you'd be more likely to think in terms of,
"I want to get the bar resource from the foo service":

    http://example.com/foo/bar

and calling

    http://example.com/foo

would return all resources of the foo service, while POSTing to
http://example.com/foo/bar would modify that resource.

So, in this regards, the Zend_Rest_Server in ZF is definitely more
RPC-like -- it maps URLs to existing *actions* on the server. Many see
this as a valid REST style; others don't.

If you want to do a more classic RESTful service, you can actually do so
quite easily using the MVC layer; you'd create a controller for the
resource, map URLs to it using the rewrite router, and then in your view
scripts create and return XML instead of XHTML.

--
Matthew Weier O'Phinney
PHP Developer            | matthew@...
Zend - The PHP Company   | http://www.zend.com/

[Shahar Evron]

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@...> 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

[Shahar Evron]

One note about my example, which might be confusing: I mention SOAP as
one example of an RPC-style protocol. AFAIK REST does not define
specific protocols - REST is just the approach or service architecture,
while specific protocols are defined "ad hoc".

A REST response might be based on HTTP alone (just a 201 or 500 response
with no body), or send some data, which can be encoded in any way, and
the "Content-type" header is used to define how. I know JSON and XML are
popular data encapsulation methods, but since REST is not really a
protocol like SOAP is, it does not specify which data encapsulation
method should be used in REST services.

Shahar.

On Tue, 2007-05-29 at 18:26 +0300, Shahar Evorn 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@...> 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

[Victor Farazdagi]

Well,
Although REST is certainly not a specification and does not go and
define a protocol, there's a conventional REST model that is based on
some well known protocols and specs. These include (you are always free
to redefine set, just follow the REST principles):

URI - as REST design style disjoints an application into semantic
resources, everything is identified and located via URL, which although
should not be analized by client application still MUST correlate to a
resource it represents in a meaningful way. So, huge URIs with a long
query strings are not welcome. Need to define some query, define it as
accessible resource. I think that Davey's assumption that REST is still
RPC, is mis-leading at least. Granted, REST service is to accept some
sort of manipulation and really does invoke some server-side code, but
there no procedure mapping like it's done in conventional RPC system,
say XML-RPC. REST is less about sending requests and getting responses,
from service dev. point of view, but is about constructing resources -
others layers are handled via well-known protocols. And as such, there
must be a resource abstraction in any valuable REST service builder
library, say abstract class on top of which other resources would be
defined. As it stands now, service is more procedure oriented than
resource-oriented and that's not the very expected by any REST service
developer (and it really messes things up, as we are forced to think in
terms of procedure and their mappings - instead of considering the
REsourceST). So, if the package should not be redesigned, then it should
really be extended - at least with Resource abstraction (some but not
all funcs of which is carried out by Rest/Server.php now).

HTTP (both for available verbs and response status codes). Although
again not dictated by Fielding's text, considering that author has
contributed to the specs, and constantly deploys the slang referencing
to how HTTP handles things, I suppose it's quite a safe bet to use it.
As such it is present in current Zend/Server.php but is an integral part
of it - for the REST does not force one to use HTTP methods for
acceptable state transfer protocol, this usage should be abstracted, so
that it could be easily substituted if service dev. would go with some
other protocol. BUT, this could be left intact as well - I really
haven't seen anyone going past the HTTP.

Content Types - well the last point of so called REST Triangle
(Resources - represented as URIs and unconstrained, Verbs - could be
represented by intentionally limited set of HTTP methods, Content Types
- generally MIME types are deployed to describe the content media of
transfered resource state). Although XML is a safe bet for API -lovers,
as you can represent almost anything with it, REST is not only about
sending XML back and forth it's also about caching - so if you represent
some image in your XML as base64 string, and the rest of values found in
that document are highly dynamic - you are killing one of the purposes
REST is claimed to be a successful theme - caching. It's better to
include the link to your image file, and make actual image available as
yet another resource with well-known content type (png, jpeg whatever),
so that intermediaries in REST talking would be able to handle saving
and reusing the cache. Shahar makes extremely good point by saying that
even HTTP's status codes (201, 204, 205 etc) would be enough for a REST
response. Should user want some fancy "die hacker!" message be sent, it
should be done via extension of resource base class.

To sum up: REST is about practices, and violating those is not the best
way of implementing the service you happen to call RESTyful. Just by
looking at current class, it's at least an insufficient presentation of
building blocks for the REST service. Btw, imo, client side's interface
(Rest/Client.php) is quite good and could safely left intact - although
I prefer to use LiveHeaders (http://livehttpheaders.mozdev.org/) for
Firefox - they just make your browser a little bit more REST-enabled.

Thanks,
Victor

P.S.Btw, Shahar, R. Fielding loves to define the REST not as
architecture but as architectural style, with architecture being more
specific (as in specifications), while style just a set of genius :)
insights on how distributed systems become popular :)

> One note about my example, which might be confusing: I mention SOAP as
> one example of an RPC-style protocol. AFAIK REST does not define
> specific protocols - REST is just the approach or service architecture,
> while specific protocols are defined "ad hoc".
>
> A REST response might be based on HTTP alone (just a 201 or 500 response
> with no body), or send some data, which can be encoded in any way, and
> the "Content-type" header is used to define how. I know JSON and XML are
> popular data encapsulation methods, but since REST is not really a
> protocol like SOAP is, it does not specify which data encapsulation
> method should be used in REST services.
>
> Shahar.
>
> On Tue, 2007-05-29 at 18:26 +0300, Shahar Evorn 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@...> 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
>>>      

[Matthew Ratzloff]

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 <[e-mail]> 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

 

[Matthew Weier O'Phinney-3]

-- Matthew Ratzloff <matt@...> wrote
(on Saturday, 05 January 2008, 12:58 PM -0800):

>
> 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 -- this is a comment I've made myself a number of times.
Unfortunately, at the time that I was helping out with tests and
documentation, I wasn't as up-to-speed on REST as I am now, and didn't
ask these important questions of the original author before it made its
way into the incubator.

Honestly, probably the best way to serve a REST app using ZF is using
the MVC (thought the original author of Zend_Rest was vehemently opposed
to doing so), and with the ContextSwitch action helper that's being
introduced as part of the AjaxContext action helper proposal, this
should be pretty trivial to accomplish.

(That proposal is at http://framework.zend.com/wiki/x/R6I, and code is
in the laboratory under the Zend_Form area.)

Now, all this said, I'll put on my devil's advocate hat, and state that
I know some feel that REST does not need to be RESTful, that the
important thing is that it simply uses HTTP for the transport. If you
look at many of the so-called REST APIs out there, it's pretty suprising
how many *don't* use XML in favor of arbitrary formats, and how many
don't necessarily follow the GET/PUT/POST/DELETE paradigms of REST nor
the idea of a URL as a resource. I personally like the idea of RESTful
resources, but many see this as merely a suggestion.

Either way... ZF will now be able to easily support either one.

> 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@...> 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
> >
> >  
> >
>
> --
> View this message in context: http://www.nabble.com/Our-REST-implementation-tp10834932s16154p14638961.html
> Sent from the Zend Web Services mailing list archive at Nabble.com.
>

--
Matthew Weier O'Phinney
PHP Developer            | matthew@...
Zend - The PHP Company   | http://www.zend.com/

[lcrouch]

I don't think I know a *lot* about REST, but I'm in the middle of this right now ... trying to build a RESTful API with ZF MVC. As I've explained in another thread in the fw-mvc list, I have found the Action Controllers to be a bit cumbersome in trying to implement a fully REST design - IMO, one in which the URI contains only nouns and identifiers, and the "action" is determined by the HTTP request method. e.g.,

GET http://localhost/module/entity-type/id1
goes to:
application/modules/<module>/<entity-type>Controller.php::getAction()

more specifically:

GET http://localhost/users/profile/groovecoder
goes to:
application/modules/users/ProfileController::getAction()

from my attempts this last week to do this via custom routes, I thought the cleanest way to fully support REST in ZF is with a Zend_Controller_Router_Rest and/or Zend_Controller_Router_Route_Rest class.

it would also be nice to be able to optionally specify identifiers b/w module and controller elements in the url:

GET http://localhost/users/groovecoder/profile
also goes to:
application/modules/users/ProfileController::getAction()

-L

On Jan 5, 2008 9:03 PM, Matthew Weier O'Phinney <matthew@...> wrote:

-- Matthew Ratzloff <matt@...> wrote
(on Saturday, 05 January 2008, 12:58 PM -0800):

>

> 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 -- this is a comment I've made myself a number of times.
Unfortunately, at the time that I was helping out with tests and
documentation, I wasn't as up-to-speed on REST as I am now, and didn't
ask these important questions of the original author before it made its
way into the incubator.

Honestly, probably the best way to serve a REST app using ZF is using
the MVC (thought the original author of Zend_Rest was vehemently opposed
to doing so), and with the ContextSwitch action helper that's being
introduced as part of the AjaxContext action helper proposal, this
should be pretty trivial to accomplish.

(That proposal is at http://framework.zend.com/wiki/x/R6I , and code is
in the laboratory under the Zend_Form area.)

Now, all this said, I'll put on my devil's advocate hat, and state that
I know some feel that REST does not need to be RESTful, that the
important thing is that it simply uses HTTP for the transport. If you
look at many of the so-called REST APIs out there, it's pretty suprising
how many *don't* use XML in favor of arbitrary formats, and how many
don't necessarily follow the GET/PUT/POST/DELETE paradigms of REST nor
the idea of a URL as a resource. I personally like the idea of RESTful
resources, but many see this as merely a suggestion.

Either way... ZF will now be able to easily support either one.

> 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@...> 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
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Our-REST-implementation-tp10834932s16154p14638961.html
> Sent from the Zend Web Services mailing list archive at Nabble.com.
>

--
Matthew Weier O'Phinney
PHP Developer            | matthew@...
Zend - The PHP Company   | http://www.zend.com/

[tfk]

On Jan 6, 2008 5:30 PM, Luke Crouch <luke.crouch@...> wrote:

> I don't think I know a *lot* about REST, but I'm in the middle of this right
> now ... trying to build a RESTful API with ZF MVC. As I've explained in
> another thread in the fw-mvc list, I have found the Action Controllers to be
> a bit cumbersome in trying to implement a fully REST design - IMO, one in
> which the URI contains only nouns and identifiers, and the "action" is
> determined by the HTTP request method. e.g.,
>
> GET http://localhost/module/entity-type/id1
> goes to:
> application/modules/<module>/<entity-type>Controller.php::getAction()
>
> more specifically:
>
> GET http://localhost/users/profile/groovecoder
> goes to:
> application/modules/users/ProfileController::getAction()
>
> from my attempts this last week to do this via custom routes, I thought the
> cleanest way to fully support REST in ZF is with a
> Zend_Controller_Router_Rest and/or Zend_Controller_Router_Route_Rest class.
>
> it would also be nice to be able to optionally specify identifiers b/w
> module and controller elements in the url:
>
> GET http://localhost/users/groovecoder/profile
> also goes to:
> application/modules/users/ProfileController::getAction()

This is how I implemented it as well. Not as nice and simple as
rolling a Zend_Controller_Router_Rest, but I basically set up custom
routes and actions and double checked the request method among all
parameters to make sure it played nice.

I think the beauty of the Zend_XmlRpc_* component(s) is that you get
to attach your class code directly and map out methods and so on, so
if this could be taken over into a Zend_Controller_Router_Rest (or
similar), that would be really nice.

Till

[lcrouch]

to me, "attach your class code directly and map out methods and so on" sounds like the XML RPC design paradigm. it wouldn't make sense to enable this as a "REST" implementation. IMO, REST is an *architecture*, while XML RPC is a http-ready api *wrapper* design to go around existing code (with a non-REST architecture).

I would almost suggest simply removing the Zend_Rest component, and merging its functionality into Zend_XmlRpc, and then enabling RESTful architecture with some REST enhancements to Zend_Controller.

-L

On Jan 6, 2008 11:44 AM, till <klimpong@...> wrote:

On Jan 6, 2008 5:30 PM, Luke Crouch <luke.crouch@...> wrote:

> I don't think I know a *lot* about REST, but I'm in the middle of this right
> now ... trying to build a RESTful API with ZF MVC. As I've explained in
> another thread in the fw-mvc list, I have found the Action Controllers to be
> a bit cumbersome in trying to implement a fully REST design - IMO, one in
> which the URI contains only nouns and identifiers, and the "action" is
> determined by the HTTP request method. e.g.,
>
> GET http://localhost/module/entity-type/id1
> goes to:
> application/modules/<module>/<entity-type>Controller.php::getAction()
>
> more specifically:
>
> GET http://localhost/users/profile/groovecoder
> goes to:
> application/modules/users/ProfileController::getAction()
>
> from my attempts this last week to do this via custom routes, I thought the

> cleanest way to fully support REST in ZF is with a
> Zend_Controller_Router_Rest and/or Zend_Controller_Router_Route_Rest class.
>
> it would also be nice to be able to optionally specify identifiers b/w
> module and controller elements in the url:
>
> GET http://localhost/users/groovecoder/profile
> also goes to:
> application/modules/users/ProfileController::getAction()

This is how I implemented it as well. Not as nice and simple as
rolling a Zend_Controller_Router_Rest, but I basically set up custom
routes and actions and double checked the request method among all
parameters to make sure it played nice.

I think the beauty of the Zend_XmlRpc_* component(s) is that you get
to attach your class code directly and map out methods and so on, so
if this could be taken over into a Zend_Controller_Router_Rest (or
similar), that would be really nice.

Till

[Shahar Evron]

+1.

This was suggested months ago IIRC, and either was not accepted or did
not receive enough attention.

Shahar.


On Sun, 2008-01-06 at 13:00 -0600, Luke Crouch wrote:

> to me, "attach your class code directly and map out methods and so on"
> sounds like the XML RPC design paradigm. it wouldn't make sense to
> enable this as a "REST" implementation. IMO, REST is an
> *architecture*, while XML RPC is a http-ready api *wrapper* design to
> go around existing code (with a non-REST architecture).
>
> I would almost suggest simply removing the Zend_Rest component, and
> merging its functionality into Zend_XmlRpc, and then enabling RESTful
> architecture with some REST enhancements to Zend_Controller.
>
> -L
>
> On Jan 6, 2008 11:44 AM, till <klimpong@...> wrote:
>         On Jan 6, 2008 5:30 PM, Luke Crouch <luke.crouch@...>
>         wrote:
>         > I don't think I know a *lot* about REST, but I'm in the
>         middle of this right
>         > now ... trying to build a RESTful API with ZF MVC. As I've
>         explained in
>         > another thread in the fw-mvc list, I have found the Action
>         Controllers to be
>         > a bit cumbersome in trying to implement a fully REST design
>         - IMO, one in
>         > which the URI contains only nouns and identifiers, and the
>         "action" is
>         > determined by the HTTP request method. e.g.,
>         >
>         > GET http://localhost/module/entity-type/id1
>         > goes to:
>         >
>         application/modules/<module>/<entity-type>Controller.php::getAction()
>         >
>         > more specifically:
>         >
>         > GET http://localhost/users/profile/groovecoder
>         > goes to:
>         > application/modules/users/ProfileController::getAction()
>         >
>         > from my attempts this last week to do this via custom
>         routes, I thought the
>         > cleanest way to fully support REST in ZF is with a
>         > Zend_Controller_Router_Rest and/or
>         Zend_Controller_Router_Route_Rest class.
>         >
>         > it would also be nice to be able to optionally specify
>         identifiers b/w
>         > module and controller elements in the url:
>         >
>         > GET http://localhost/users/groovecoder/profile
>         > also goes to:
>         > application/modules/users/ProfileController::getAction()
>        
>        
>         This is how I implemented it as well. Not as nice and simple
>     &