Debunking the Myths of RPC & REST

etherealbits.com

10 points·tysont··2 comments

The article mentions that the only "contract" you have with the client is a GET request to a top-level URI, and from there, everything should be described via some sort of hypertext, and the application can go from there.

I just don't understand how that's supposed to work in the context of, say, a server application. In a browser, you have a human to make sense of the hypertext and decide what looks worth clicking on, which forms look like you want to fill out.

In an API, I already know, by the fact that I'm writing an application, what I want to do. I want to delete this customer, run a garbage compaction on a repository, search for new records. What's the point of "discovering" these URIs via hypermedia?

I think it depends if you are building a consumer API or an internal API. If you are just looking for a way to build a client to your already known (and owned) service, you could write a trivial client if the API implements HATEOAS.

For building something that uses an API but provides something else (not just a dummy client), I find it unnecessary.

At the same time, for me at least, the idea is you do not need to go 100% with this. In fact, I prefer to just take some ideas out of it. For instance, maybe an API call returns a list of _things_. Assuming you have another point on your API that provides more resources from this _thing_ (resources that are so numerous you would not provide on the previous point), you could include an href on each one of these objects. That way, if clients implement it correctly, you can keep some retro compatibility or control on the way these _things_ are served.

Now that I think of it, this article[1] linked in a comment[2] on another story may answer your question better.

[1]: http://martinfowler.com/articles/richardsonMaturityModel.htm...

[2]: http://news.ycombinator.com/item?id=4870322l

Reply on news.ycombinator.com