As further input to the discussion, Rickard posted a follow up: http://www.jroller.com/rickard/entry/rest_and_the_missing_link
Summing that one up in one sentence, he stresses the importance of having proper links, which can be used to discover what you can do, and that in such a way that they are fairly resistant to change. On 17 Oct 2010, at 22:58 , Angelo van der Sijpt wrote: > Well, that's indeed a very nice analysis. In a nutshell: > - Don't expose infrastructure (e.g. your database) through a REST API He does conclude however that it is acceptable to make them accessible over HTTP, but since the API would not be true REST we should not call it that if we do. > - The entity layer seems like a great candidate, but lacks application logic, > - The application layer can best be 'REST-ified' by taking the entities, and > wrapping them in link-based application logic. > > I totally agree with his main point: not everything that uses HTTP is REST > (not by a long shot), and not everything that should be exposed using HTTP > should comply to REST. I'd say the problem lies in the interpretation of > Fielding's term 'resource' to main 'entity'. > So, surely, answering every question "how should x and y communicate" with > "what a silly question, REST of course!" is an oversimplification. Agreed, having "everything" communicate using REST might not make sense. > Applied to our own case, I like his two-step actions (first get some resource > to find out the exact properties, then post to the same resource as a manner > of form-post) as a way of working with things like gadget and users; Me too. > I believe this can be very well wrapped around the OSGi service we have for > those already, but we should come up with a uniform 'shape' of the types of > services we use for that. Thinking along those lines, it seems that the > services that are less suited for wrapping (e.g. persistence) are more > infrastructure services, so should not be exposed at all. That leads to the question: if, from a design point of view, it's not appropriate to expose these using REST, then how should we expose them? I don't think "not at all" should be taken too literal, so: 1) do we simply expose them as a service, using remote services when necessary 2) do we go fo the "accessible over HTTP" option (which is not REST) 3) do we force the lipstick on the chicken and try to do it with REST anyway This is a fundamental discussion, since up til now we've mostly stated "everything is connected via REST". > There are a number of open questions that we need to answer before we can > start happily wrapping our services. For instance, what about user- or role > dependent resources, like '/gadgets/mine'? What does 'logging in' mean in > this context? Do you post to '/session/create', and get back a session which > you can use to find 'your' stuff, or should all services be user-aware? And > tenant-aware? And application-aware? Interesting questions indeed. Sessions (for holding on to state) at first don't seem to fit in the REST model. However, if you model them with REST they just become resources, so that actually sounds like a good way to approach it. Logging in is an interesting one. I think this should be done by navigating links too. I agree we need to do some designing before we start coding here. A good approach would be to take some of our use cases and define how the REST calls would look like in each step. Greetings, Marcel > > On Oct 16, 2010, at 10:05 PM, Marcel Offermans wrote: > >> Hey all, >> >> Rickard ?berg just wrote a nice article on where to use and where not to use >> REST. Check it out here: >> >> http://www.jroller.com/rickard/entry/rest_api_for_infrastructure_domain >> >> WDYT? >> >> Greetings, Marcel >> >> >> _______________________________________________ >> Amdatu-developers mailing list >> Amdatu-developers at amdatu.org >> http://lists.amdatu.org/mailman/listinfo/amdatu-developers > > _______________________________________________ > Amdatu-developers mailing list > Amdatu-developers at amdatu.org > http://lists.amdatu.org/mailman/listinfo/amdatu-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101018/3940f6e1/attachment.html
