Re: Our REST implementation

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 :)