Hacker News Reader

Comment by pixie_ | Hacker News Reader

It does encourage more endpoints because I can't include data from two different objects in a response. They should be GET separately. With highly relational data where I need to create an endpoint that returns information regarding 50 different object types, how should I do that? My rolled up response is no longer REST.

When I need to act on that data and call an API that can do a variety of CRUD operations to 50 different objects types, how should I do that in a REST way?

It leads to developers creating a multitude of APIs to interact with those 50 different object types. Just so they can say their API is REST. For someone trying to use the API it's a nightmare.

View on HN

Nonsense. A URL is a resource endpoint. If a resource is a composition of other resources, it is perfectly acceptable to return all composed resources.

Let's try an example: A shopping application, with customers, products and orders. An order composes a customer and all products that were ordered. You'd have endpoints for retrieving a customer (/customer/<id>/), a product (/product/<id>/) and an order (/order/<id>/). When retrieving the order, nothing in REST prohibits you from returning full information about the user and about the products.

Now, advancing the discussion, the reverse complaint is that it is wasteful returning a full information complement when GETting an order. Easy peasy. Just use proper mime types and an Accepts header. Pass in "Accepts: application/json+order+deep" or "Accepts: application/json+order+plain" from the client side signaling the kind of response you want from the server.

> Pass in "Accepts: application/json+order+deep" or "Accepts: application/json+order+plain" from the client side signaling the kind of response you want from the server.

This is an interesting approach, but I'm wondering how this interacts with caching: how does the client properly differentiate between the two calls ? (I guess the 'Vary:' header has something to do with this, but I never used it directly).

Also, why change the content type when one could just add some query string parameters? With many libraries, both client and server side, this is probably easier to do.

> Also, why change the content type when one could just add some query string parameters?

For the same reason you use HTTP verbs. It conveys more information within the standard. Software in the middle may act upon it. A cache is a perfect example. Imagine the cache sees a request accepting json or xml. The server chooses to return json. A second request accepts only json. The cache knows, from the standard, that the first response is valid for the second request.

Not that you can't configure something like Varnish to reproduce this behavior with query params, but with the standard oriented approach you get the correct caching behavior out of the box.

Reply on news.ycombinator.com