3 ms·
In a lot of ways I think what you are saying is actually in line with what the article is saying: Most people don't actually understand REST and it is leading
by qyv 11y ago
In a lot of ways I think what you are saying is actually in line with what the article is saying: Most people don't actually understand REST and it is leading to a lot of poorly designed API's. Unfortunately, the zealots are often the worst offenders in propagating the misunderstandings. For instance:
> Surface area and complexity are a big deal. REST encourages creating a CRUD interface for every single resource. I've met people who have created literally 100 endpoints upfront for a small application - how is that maintainable?
I disagree, REST does NOT encourage a CRUD interface for every single SERVER SIDE resource. Your rest resources should be modelled after the resources your CLIENT needs. You should not be designing your client resource models based on the underlying server models regardless of using REST, SOAP or some kind of roll-your-own system.
- pixie_ 11y agoIt 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.
- sergiosgc 11y agoNonsense. 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.
- mrighele 11y ago> 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.
- sergiosgc 11y ago> 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.