Skip to content

Comment on Debunking the Myths of RPC & RESTparent

Comments

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

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.