Comment by kelseyfrog | Hacker News Reader

Comment by kelseyfrog | Hacker News Reader

An earnest answer? Because few people have taken the couple hours(?) and read Roy Fielding's dissertation from start to finish. The biggest likely reason for not doing so is that frankly a bunch of people simply don't care, and why should they. There's very little incentive to do so. In fact, the fewer people that do, the less of an incentive there is - there is no one can call them out on it and they can reap the rewards of calling an API RESTful despite the accuracy of the statement.

Having worked in an organization where people were very familiar with the academic definition of REST, the biggest benefit of being a backend developer was that when client-side folks depended on nonRESTful behavior, we had some authority to back that claim. It gave us leeway in making some optimizations we couldn't have made otherwise, and we got to stick to RFCs to resolve many disputes rather than use organizational power to force someone to break compliance to standards. I suppose it meant that we were often free to bikeshed other aspects of design instead.

The dissertation is neither a specification or a standard which has led to decades long bickering of what 'REST' really is.

Edit: See how this post has zoomed to hundreds of comments in just minutes by people arguing the 'one true REST'. The situation is insufferable.

For sure. It's not even focused on APIs. REST is an architectural style. I don't think I've ever heard the term RESTful architecture in design meetings or online discourse. That should say that something is off.

I tend to find it helpful to ask, "is this proper REST as in HATEOAS, or is just 'REST-ish'?" It's usually just REST-ish: predefined URL patterns, roughly 1:1 with specific resource-APIs; they care about your HTTP verb and return JSON (but usually not with a lot of URLs in that JSON).

It's funny because HATEOAS violations were single-handedly the most common violation made by the client team during my time there. They loved hard coding URLs and willfully ignoring hypermedia.

See, to me, this sounds like a failure to listen to your customer. They were telling you that well known URLs were useful to them, and you were forcing them to make more compromises so that you could make fewer.

We answered to the architecture team on matters of design. If the client team had had beef with the design, the client team took it up with them.

What do they do if they don’t hard code it?

   bookHotelUri = listHotelResponse.data.urls[4];

Or

    listHotelResponse .data.urls.find(u=>u.action===‘book’).url

?

Sort of. Verbs are still eschewed so rather than finding a 'book' link, it would be a 'booking' link to which a POST could be made to create a new booking. As a note, "Booking" is a confusing example because while a hotel booking is a noun it at first glance reads as a progressive tense verb.

So instead of a hard coded url it's a hard coded reference to a url? How does it deal with a breaking changing? Say the order of the links changes? It doesn't seem like this works without some out of band information.

They are keyed using rels. You're right, they aren't relying on order; that would be terrible. And yes, JSON doesn't "have" rels. This is worked around by specifying a mimetype which does. Is it turtles all the way down? Yes, but not all turtles are equivalent. You should already be specifying a "Content-Type": application/json, it's not too much to change that to application/vnd.api+json and write a spec somewhere.

    listHotelResponse.data.urls.find(u=>u.rel===‘booking’).url

Web linking is defined in https://www.rfc-editor.org/rfc/rfc8288.html and that's the basis for using rel as well as a host of other attributes.

Counterpoint: This all got a lot worse and more confusing for me when I read the dissertation. What people seemed to call RESTful struck me as a bit convoluted but fine and workable. But after I read the dissertation, it was clear that all that was "wrong", but I was left without any real concept of what was both right and workable. It took me years to realize I could just ignore the whole thing and focus on designing useful interfaces. (And that, indeed, this is what most people had been doing already.)

I think you're missing a little historical context here, but maybe you were already more experienced back then than I was, for example (which means your bubble was in the know and the unwashed masses weren't). I started making websites in 1998 and earning money with it in 2001ish (that's the year Wikipedia launched) and imho back then it was a lot harder to find the 'correct' way with teaching yourself. I saw REST/RESTful and best practices for the web mostly develop after 2005-2008 (yeah, around the time there was the great Rails exodus as well) and people started to standardize more. What I'm trying to say is that it was all more the Wild West in web development and by the time people had more insight, the naming/switch to JSON had already begun. I also don't remember when I read the REST dissertation first, probably only much later than 2001.

That aligns roughly with my experience. What I mean is that even post 2010 most people haven't read the material and continue to promote weird frankenapis which they call RESTful based on scrap anecdotes or secondhand messageboard info, or hermeneutical readings of other API designs.

Reply on news.ycombinator.com