Best practices for REST API design (2020)

Re:Best practices for REST API design (2020) by n_e on Monday February 22, 2021 @12:41PM (#26227487)

> On the flip side, I've never been frustrated by getting too many fields back from an API

A pretty common use-case I have is needing to support these three things :

- A “big object” list screen (where retrieving the whole objects would make the query return megabytes off data)

- A “big object” details screen (where I need the full object)

- Programmatically getting many big objects

With GraphQL it involves writing one (or two) straightforward queries, while with REST it would require more thought or code.

[ Parent | on HN ]

Re:Best practices for REST API design (2020) by criddell on Monday February 22, 2021 @05:27PM (#26231528)

> With GraphQL it involves writing one (or two) straightforward queries, while with REST it would require more thought or code.

Aren't you just pushing the work to the back end? The GraphQL resolver is a new layer of complexity while with REST is more straightforward.

[ Parent | on HN ]

Re:Best practices for REST API design (2020) by nojvek on Tuesday February 23, 2021 @02:30AM (#26234715)

Yes, but you don’t have that many network round trips.

[ Parent | on HN ]

Re:Best practices for REST API design (2020) by criddell on Tuesday February 23, 2021 @08:36AM (#26237036)

Maybe, maybe not.

If there is some sequence that is used a lot and you've determined it to be a bottleneck, you can write a custom endpoint for it.

[ Parent | on HN ]