Best practices for REST API design (2020)
stackoverflow.blog
Best practices for REST API design (2020)
1–10 of 273 posts
Re: Best practices for REST API design (2020)
#2I've written a comprehensive one on this topic a few years ago:
https://www.vinaysahni.com/best-practices-for-a-pragmatic-re...
Re: Best practices for REST API design (2020)
#3I’ve also found the Microsoft API guidelines helpful (especially for error handling).
https://github.com/microsoft/api-guidelines/blob/vNext/Guide...
Re: Best practices for REST API design (2020)
#4Great post. Nothing flashy, walks through basics and principles. I do love the simplicity of REST and unless you need some graph would recommend folks stick with it over GraphQL
Re: Best practices for REST API design (2020)
#5> Then if we try to submit the payload with the email value that already exists in users, we’ll get a 400 response status code with a 'User already exists' message to let users know that the user already exists. With that information, the user can correct the action by changing the email to something that doesn’t exist.
I was always under the impression that 409 would be the "correct" code here, while you'd use 400 if the API user didn't supply an email at all, for example.
Re: Best practices for REST API design (2020)
#6All these "best practices" are exactly why I embraced GraphQL quickly and flushed "REST" down the toilets for big projects (http+json is fine for small ones, since no lib overhead). GraphQL is unashamedly the new SOAP. I.e. we have a spec, not a series of "best practices" thus endless architectural debates where people are shamed for 'doing it the wrong way' online.
- Accept and respond with JSON: No, why? what if I want to work with XML? or format X or Y?
- Use nouns instead of verbs in endpoint paths: I don't care about that
- Name collections with plural nouns: I don't care about that
- Nesting resources for hierarchical objects: No, why?
- Handle errors gracefully and return standard error codes: nothing to do with REST specifically.
- Allow filtering, sorting, and pagination: yes, good luck coming up with the right query structure and sticking to it.
- Maintain Good Security Practices: nothing to do with REST specifically.
- Versioning our APIs: And here we are. How many HATEOAS people claimed it was blasphemy and it missed the point of REST?
None of these are an issue with GraphQL, just like they weren't an issue with SOAP. You get a schema both the client and the server must agree with, end of story.
As I said to a dev once, if your 'best practices' can't be automated with a CI tool, then you need to worry about creating that tool first...
Re: Best practices for REST API design (2020)
#7I interrupted my reading at 'Accept and respond with JSON' to write this comment, before I skipped over that section and returned to reading the rest.
Folks that aren't aware of Webmachine should take a look:
https://github.com/webmachine/webmachine
The 'Accept' header should determine the response type, but content negotiation is something that few bother to implement. Webmachine does that for you, among other things like choosing the correct status code for your response.
Also, shameless plug for my OCaml port:
Re: Best practices for REST API design (2020)
#8All these "best practices" are exactly why I embraced GraphQL quickly and flushed "REST" down the toilets for big projects (http+json is fine for small ones, since no lib overhead). GraphQL is unashamedly the new SOAP. I.e. we have a spec, not a series of "best practices" thus endless architectural debates where people are shamed for 'doing it the wrong way' online. - Accept and respond with JSON: No, why? what if I…
> GraphQL is unashamedly the new SOAP
...may not be the advertising you think it is.
Re: Best practices for REST API design (2020)
#9All these "best practices" are exactly why I embraced GraphQL quickly and flushed "REST" down the toilets for big projects (http+json is fine for small ones, since no lib overhead). GraphQL is unashamedly the new SOAP. I.e. we have a spec, not a series of "best practices" thus endless architectural debates where people are shamed for 'doing it the wrong way' online. - Accept and respond with JSON: No, why? what if I…
Never understood the hype around GraphQL.
You want to know how to halve your performance and responses/s on your service? add graphql.
All things that GraphQL claims to do can be implemented in RESTful services easily.
If you want specificity in your query fetching, just add query params or put them in the request body
If you want schema validations, there are many libraries that help you with that.
And if you want data from multiple resources from different endpoints, what exactly is stopping you from implementing that in REST?
Also, GraphQL has a steeper learning curve as opposed to REST.
never understood graphql. To me its just an abstract layer between the front end and back end, adding to the already complex stack.
Re: Best practices for REST API design (2020)
#10All these "best practices" are exactly why I embraced GraphQL quickly and flushed "REST" down the toilets for big projects (http+json is fine for small ones, since no lib overhead). GraphQL is unashamedly the new SOAP. I.e. we have a spec, not a series of "best practices" thus endless architectural debates where people are shamed for 'doing it the wrong way' online. - Accept and respond with JSON: No, why? what if I…
[deleted]