Rickard Oberg explains how to expose use-cases to solve the linking problem in RESTful APIs, and how this will simplify both API development, documentation, as well as client development.
Rickard Oberg has worked on several OpenSource projects that involve J2EE development, such as JBoss, XDoclet and WebWork. He has also been Principal Architect of the SiteVision CMS/portal platform, where he used AOP as the foundation. Now he works for Neo Technology, building the leading graph database Neo4j. Twitter: @rickardoberg
Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
It seems quite a jump from the more common Rest API examples.
I'm not a Rest purist, I'm just tired of one side of the Rest camp preaching their approach and the other side (or maybe just the real world) going off on their own way. You may want to call it pragmatic Rest or not Rest at all, its getting to the stage where nothing surprises me about what can be called Rest nowadays.
Road to REST ?
thank you for retracing the "history" behind REST. We are now 7 years after Tim Bray's infamous post on "The End of SOA" and we are still looking for the "road to REST"? really?
However, the case (so to speak) that you have built in this presentation is no stronger than the case that was built to support a Data or Domain approach to REST. The fundamental flaw of HATEOAS is that the client and the resource owner need to have a shared understanding of the links. You keep making arguments at the UI level where a user (as in human) can reason about the meaning of a link. However an arbitrary client cannot make much more sense of any relationship unless it has been instructed to do so, in some way.
Sure, it's interesting to expose "links" based on back-end state, such that the client do not travel paths that will lead to exceptions, but we are no even a nanometer closer to emulate how a user uses a browser. Roy's REST is brilliant, as I said it many time, but REST needs the intelligence of a human to work. This was clear from the beginning. There is simply no way around it.
All the hard core RESTafarians are now cornered to make HATEOAS work, and as I predicted 7 years ago, this effort will fail, because it only works with the intelligence of a user or an extremely heavy shared understanding. HATEOAS is the UDDI of SOAP, it will lead to the same sort of failure: "discovery" and "dynamic binding" are extremely expensive, far more expensive than a "coupled understanding" at the API level.