Hi, Well, that's indeed a very nice analysis. In a nutshell: - Don't expose infrastructure (e.g. your database) through a REST API - 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. 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; 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. 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? More questions than answers, but this should at least get the conversation started. My two cents, Angelo 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.amdatu.org/pipermail/amdatu-developers/attachments/20101017/44b4b34a/attachment.html
