Hi Markus,
Thanks.. I understand what you mean more so now. I am still not quite sure I see how asking a client to store their "cart" data rather than updating a cart DB on the server side is any less restful. I say that because.. if we can put an item in the cart and remove it from the available items that are stored on the server side... why can't we keep the cart on the server side as well? I understand the notion of statelessness.. but my understanding of that is sort of how servlets and session cookies work.. stateful being the session retains a cookie going back and forth... but moving that HttpSession data to a DB table, while maintaining it's state.. the request/response are stateless. From one request to the next, there is no state.. the logic in the server side has to use something that comes in from the request to figure out the stored state.. in my example, tying the authentication to a user table, then from there being able to get the cart data/state
from the cart table based on that user. I guess I am unclear as to why this is unRESTful.
Also, what drives me to drill down on this is some stuff I am working on when I can spare some cycles... an eventual public service that might be consumed by many developers. I don't know how I explain to them that my API is a true RESTful API and as such, they must send me (and thus maintain) the state on every request (depending on the URI chosen by the client... if they choose Cancel, of course they don't have to send all the contents). I suppose this is where I thought REST would be so beautiful.. using such an easy HTTP call with minimal effort to add new items to the cart, get a list of what is in the cart, delete an item from the cart. Having every developer actually maintain and send me the cart contents every time a link is pressed (that requires the "state" of the cart.. it's contents), seem's deterring to me. I can imagine a lot of developer not understanding why this is done this way. In other words, it almost seems like for me to provide a
really nice/easy RESTful API, I also have to provide some URIs that are NOT REST based calls in order to maintain the state of a cart on the server side. I am having a hard time grappling with this mixed API design.... on the one hand, the server side keeps a DB of items that can be manipulated.. added to the cart, updated, etc. On the other hand, the actual cart data for each user is up to them (er..the developer consuming the API) to keep track of send when needed, etc.
So let me throw this out there.. I'll probably get slammed for it.. especially if Roy reads it.. but perhaps while Roy's REST is sort of gospel right now, perhaps this sort of hybrid use of REST is more useful than just pure REST.. and I know you and others are not saying we CANT do this.. but if the REST community is pushing the notion of REST.. and more and more developers (like myself) start to understand what a truly RESTful API is and doing it right, then some of the things I thought the REST I was doing (which are probably more HTTP RPC) go away.. and now I can't offer a pure REST API to do things like provide a public CART service that does NOT entail the client side having to maintain the cart contents. I like the "current" REST ways because it allows a much easier to use API than web services. Using the simplicity of HTTP calls with authentication as many of us do now, even those of us not using HATEOAS but publishing a SDK doc that indicates
ALL the urls a consumer can make at any point (as long as authentication works).. I don't know.. it just seems to alleviate a lot of the web services, SOAP, stuff like that that while not terribly difficult, is not nearly as clean/pretty as this sort of ad-hoc REST a lot of us are currently employing. So maybe rather than pushing this idea of pure REST on the community, we should coin what I think you and/or Jan call an HTTP API... perhaps come up with a better name for it.. or maybe not... I honestly don't know if I would want to become a pure REST based API with what I feel are now limitations of the meaning of a RESTful API. I like that I can provide an SDK doc with clear info on calls, what to send in, and what comes back under various circumstances. I like the idea of HATEOAS even better, but with the same context of how I am using REST with Jersey today.. publish a SDK doc that indicates the first URL to go to, depending on authentication you'll
get back some subset of links you can then use. From there, it goes on and on, but at least things like state that the service provides can be contained in a dB on the server side and still provide a very clean easy to use REST-like API and keep the client side relatively easy as well.
--- On Wed, 2/17/10, Markus Karg <markus.karg_at_gmx.net> wrote:
From: Markus Karg <markus.karg_at_gmx.net>
Subject: RE: [Jersey] JAX-RS == REST? Or not? (was Re: [Jersey] What HATEOAS actually means)
To: users_at_jersey.dev.java.net
Date: Wednesday, February 17, 2010, 9:53 AM