I'll say that the religious approach some take with REST is weird to me. Apparently there's some promised utopia behind getting REST perfect but in the end, nobody does it right but everybody makes it work for their case<p>Getting the linkrels back is great, but it is up to your frontend to interpret them and display them back. There is no "magic" there because only humans know what does cancel/change mean, not the computers
> This allows us to invoke GETs safely any number of times in any order and get the same results each time. An important consequence of this is that it allows any participant in the routing of requests to use caching, which is a key element in making the web perform as well as it does.<p>What conditions for a restful api does this come in handy?<p>In most implementations I have had the requests are as quick to figure out if anything has changed as it is to return the result.<p>The problem is not that a get changes the result, it is a post from some other client has changed it in the interim and you want the freshest data.<p>Id imagine it is most useful in serving static content that has large payloads, which most of my apis don’t serve.
Calling an API without hypermedia a “level two REST API” is like calling a lettuce and tomato sandwich a “level two BLT”. You’re missing an intrinsic piece of the puzzle and anybody actually expecting a BLT is going to be disappointed.<p>Why are people so adamant that they <i>absolutely must</i> call non-REST APIs “REST”? Names are free, you don’t have to hijack the name of something else!