-1

I am trying to follow RESTful principles and a little confused on how "Eager" or "Lazy" endpoints would be set up.

For example, a
Shop has many Products
Products have many Ingredients.
Products have many Packging

Of course a "bad" endpoint that would fetch eagerly would be:

api/shop/1

Would return shop id 1's details but also with:
ALL the Products
ALL the Product's Ingredients
ALL the Product's Packging

This of course is a crazy model...so I can only guess RESTful is "always lazy" by default?

But with "lazy be default" say you want to get 10 different products AND their ingredients...

api/shop/1/product/1/ingredients
api/shop/1/product/2/ingredients
api/shop/1/product/3/ingredients

The number of requests is getting a little high...10 seperate HTTP requests for the 10 products.

So lastly, do you instead tend to design the RESTful endpoints based on what the front-end/consumer may want as opposed to modelling the business/database?

api/shop/1/product-details?productId=1,2,3,4,5,6,7,8,9,10

Is the above strictly "RESTful"?

So I guess the real underlying question is sort of:
Is RESTful API design a model of the Data or a model of the Views?

Jcov
  • 2,122
  • 2
  • 21
  • 32

1 Answers1

1

Is RESTful API design a model of the Data or a model of the Views?

Views is closer -- it's a model of resources

Your data model is not your object model is not your resource model is not your affordance model. -- Amundsen

The simplest analogy is to look at java script in an HTML page

  • we can embed the java script in the HTML page
  • we can link to the java script from the HTML page.

Both approaches work - they have different trade offs, primarily in how caching works.

Coarse grained resources are somewhat analogous to data transfer objects; exchange a large representation in a single request/response, and then the client can do lots of different things with that one representation.

Fine grained resources give you more control of caching strategies (the different parts can expire at different times), and perhaps respond better to scenarios where we expect the client to be sending back edited representations of those resources.

One issue that fine grained resources have had is the extra burden of round trips. HTTP/2 improves that story, as server push can be used to chain representations of multiple resources onto a single response -- all of the fine grained resources can be sent in a single burst.

But even so, we're talking about identifying resources, not database entities.

https://stackoverflow.com/questions/57420131/restful-syntax-is-it-eager-lazy-or-both

That's an identifier for a web page about a question

https://api.stackexchange.com/2.2/questions/57420131?site=stackoverflow

That's a different resource describing the same question.

REST API's aren't about exposing your data model via HTTP, they are about exchanging documents so that a client can navigate a protocol that gets useful work done. See Webber 2011.

VoiceOfUnreason
  • 52,766
  • 5
  • 49
  • 91