The state of Zend_Rest

[Tom Sommer]

There are two outstanding bugs that render Zend_Rest_Client pretty broken in most situations.

One (ZF-2215) deals with Zend_Rest_Client sending "corrupt" requests (Server don't receive the correct order of arguments), another (ZF-2467) with one being unable to send two Zend_Rest_Client calls after each other.

I was wondering, what is the state of Zend_Rest_Client, since these (seemingly simple) bugs go unnoticed?

[lcrouch]

I think there's been some discussion about this lately and that most people agree Zend_Rest is an improper component. most of its functionality is, or should be, in Zend_Xmlrpc, and Zend_Rest should be removed, right?

it sounds like there's interest in making proposals to introduce RESTful architecture implementation(s) into Zend_Controller, though.

-L

On Jan 23, 2008 7:01 AM, Tom Sommer < mail@...> wrote:

There are two outstanding bugs that render Zend_Rest_Client pretty broken in
most situations.

One (ZF-2215) deals with Zend_Rest_Client sending "corrupt" requests (Server
don't receive the correct order of arguments), another (ZF-2467) with one
being unable to send two Zend_Rest_Client calls after each other.

I was wondering, what is the state of Zend_Rest_Client, since these
(seemingly simple) bugs go unnoticed?
--
View this message in context: http://www.nabble.com/The-state-of-Zend_Rest-tp15041122s16154p15041122.html
Sent from the Zend Web Services mailing list archive at Nabble.com.

[Davey Shafik]

On Jan 23, 2008, at 10:07 AM, Luke Crouch wrote:

> most people agree Zend_Rest is an improper component. most of its  
> functionality is, or should be, in Zend_Xmlrpc, and Zend_Rest should  
> be removed, right?

WRONG.

http://en.wikipedia.org/wiki/REST#REST_versus_RPC

I 100% wholeheartedly do NOT agree with this, I have no clue where you  
got this idea from, but I suggest you do some reading, starting with  
the link above. XML-RPC is a specific format of requests and response  
contents, which you can do in a RESTful way, but XML-RPC has to be  
RPC, so you can't roll REST into it.  I think where you're running  
into trouble, is both Zend_Rest and Zend_XmlRpc are using XML output.  
IN theory, we could make the serialization modular, so rather than  
having Zend_Json_Server (incubator only, I believe) you would have:

Zend_Rest_Xml
Zend_Rest_Json
Zend_Rest_Php

Where each of these could be passed in as the serializer/unserializer  
and Zend_Rest would just handle the incoming request in a RESTful way,  
but that really requires it to be a front-controller replacement. In  
it's current implementation, it's a pre-built, RPC-ish handler, for  
REST requests using XML serialization.

I use this for my current application:

// getfoc.us/api/$version/$class/$id/$method
        $router->addRoute(
                'api',
                new Zend_Controller_Router_Route('/api/:version/:item/:id/:method/*',
                                                                                array(
                                                                                        "controller" => "api",
                                                                                        "action" => "handle",
                                                                                        "version" => "v1",
                                                                                        "item" => null,
                                                                                        "method" => null,
                                                                                        "as" => null,
                                                                                        ))

So you end up with /api/v1/task/861/complete

This isn't perfect, because anything that modifies the data, should be  
a POST, anything that is just retrieving it, should be a GET, etc, but  
in my case you end up with:

/api/v1/task/861/get to retrieve a task, because I wrap class methods  
with the RESTful calls, and actually, you could use a POST or GET  
request, I don't really care :)

I just try to make my URLs, make sense, be consistent, be guessable,  
and be friendly.

Everything then goes to the API controller, and hits the handler()  
method, which then takes the rest of the parts of the URL to form a  
request array I pass into the appropriate web service handler (because  
I allow for both REST and JSON output and could easily allo XML-RPC or  
SOAP)

- Davey

[lcrouch]

I have no clue where you
got this idea from,

I got the idea from Zend_Rest itself. if you look at Zend_Rest_Server usage, it's XML-RPC. where is the awareness of the HTTP uniform interface methods? or any helpers to create consistent and meaningful URI's?

I don't suggest Zend_Rest should be moved to Zend_XmlRpc because I think the two architectures - REST & XML-RPC - are the same, but rather because we know they're different. As is, Zend_Rest is just another XML-RPC implementation, not a RESTful implementation, and has much overlapping and duplicate functionality with Zend_XmlRpc.
 

Zend_Rest would just handle the incoming request in a RESTful way,
but that really requires it to be a front-controller replacement. In
it's current implementation, it's a pre-built, RPC-ish handler, for
REST requests using XML serialization.

yes, we agree, my thoughts exactly - real RESTful implementation needs to be cooked into the MVC (mostly C) implementation, not just by tacking XML-RPC onto classes, as Zend_Rest currently does. though rather than a front-controller replacement, it would probably be easier to just make some Rest helper classes in Zend_Controller:

Zend_Controller_Router_Rest
could duplicate rewrite routing behavior for module & controller, but use HTTP request method for choosing action method ...
/:module/:controller/:identifier
e.g.,
GET /docs/doc/18
modules/docs/controllers/DocController.php :: getAction
POST /docs/doc
modules/docs/controllers/DocController.php :: postAction
PUT /docs/doc/18
modules/docs/controllers/DocController.php :: putAction

Zend_Controller_Action_Helper_Rest
could do all kinds of helpful things, especially with HTTP headers:
 * inspect the 'Accept' header of the HTTP request and use it to choose between JSON, XML, XHTML, or any other view template
 * set an appropriate Content-Type header in the response
 * detect redirects and send 3xx response code along with appropriate Location header
 * check for X-HTTP-Method-Override to allow PUT and DELETE requests via overloading POSTs

these are just a couple examples of useful components to enable RESTful functionality. it's much more helpful in implementing RESTful architecture than just slapping XML-RPC onto pre-constructed classes, as Zend_Rest_Server currently does.

So you end up with /api/v1/task/861/complete

This isn't perfect, because anything that modifies the data, should be
a POST, anything that is just retrieving it, should be a GET, etc, but
in my case you end up with:

/api/v1/task/861/get to retrieve a task, because I wrap class methods
with the RESTful calls, and actually, you could use a POST or GET
request, I don't really care :)

not only is this not perfect, it isn't RESTful. in a ZF RESTful architecture, we shouldn't use non-identifying tokens in the URI - 'complete' and 'get' do not identify the resource, but rather the operation. one of the most fundamental principles of RESTful architecture is to use the standard HTTP methods for the method to perform against the resource. it's more RESTful to request:

GET /api/v1/task/861
to get the 'task 861' resource, and then

PUT /api/v1/task/861
to update the task e.g., with status=complete in the PUT body. 

 

I just try to make my URLs, make sense, be consistent, be guessable,
and be friendly.

completely agree. I think Rails and Django both have really good RESTful architecture implementations which standardize the URI's that expose the resources and related representations (like forms to create and edit the resources). I think we should add similar necessary classes to the Zend_Controller and Zend_View components to enable full RESTful MVC architecture with ZF and scrap the Zend_Rest component.

-L

[Matthew Weier O'Phinney-3]

-- Luke Crouch <luke.crouch@...> wrote
(on Monday, 18 February 2008, 06:31 PM -0600):

> yes, we agree, my thoughts exactly - real RESTful implementation needs to be
> cooked into the MVC (mostly C) implementation, not just by tacking XML-RPC onto
> classes, as Zend_Rest currently does. though rather than a front-controller
> replacement, it would probably be easier to just make some Rest helper classes
> in Zend_Controller:
>
> Zend_Controller_Router_Rest
> could duplicate rewrite routing behavior for module & controller, but use HTTP
> request method for choosing action method ...
> /:module/:controller/:identifier
> e.g.,
> GET /docs/doc/18
> modules/docs/controllers/DocController.php :: getAction
> POST /docs/doc
> modules/docs/controllers/DocController.php :: postAction
> PUT /docs/doc/18
> modules/docs/controllers/DocController.php :: putAction

Could you write up a proposal for the above?

> Zend_Controller_Action_Helper_Rest
> could do all kinds of helpful things, especially with HTTP headers:
>  * inspect the 'Accept' header of the HTTP request and use it to choose between
> JSON, XML, XHTML, or any other view template
>  * set an appropriate Content-Type header in the response
>  * detect redirects and send 3xx response code along with appropriate Location
> header
>  * check for X-HTTP-Method-Override to allow PUT and DELETE requests via
> overloading POSTs

A lot of this functionality is now available in the ContextSwitch action
helper, though some of it -- e.g., header detection -- is not yet. I'd
love to have your input on how we can make it a stronger offering for
implementing RESTful services.

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

[Matthew Ratzloff]

On Tue, February 19, 2008 4:55 am, Matthew Weier O'Phinney wrote:

> -- Luke Crouch <luke.crouch@...> wrote
> (on Monday, 18 February 2008, 06:31 PM -0600):
>> Zend_Controller_Router_Rest
>> could duplicate rewrite routing behavior for module & controller, but
>> use HTTP
>> request method for choosing action method ...
>> /:module/:controller/:identifier
>> e.g.,
>> GET /docs/doc/18
>> modules/docs/controllers/DocController.php :: getAction
>> POST /docs/doc
>> modules/docs/controllers/DocController.php :: postAction
>> PUT /docs/doc/18
>> modules/docs/controllers/DocController.php :: putAction
>
> Could you write up a proposal for the above?

I'd love to see this as well, Luke.

-Matt

[mattcrouch]

As long as all the Matts are chiming in, I would also like to see this