BT

InfoQ Homepage Presentations Road to REST

Road to REST

Bookmarks

Bio

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

About the conference

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.

Recorded at:

May 03, 2013

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Use Cases?

    by Mike Lythgoe /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm surprised this hasn't been slated for using Use Cases, rather than "noun based", resources.
    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 ?

    by Jean-Jacques Dubray /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Rickard,

    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.

  • Re: Road to REST ? - shared understanding

    by Jan Vissers /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    would ALPS help to solve this 'shared understanding' issue?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.