APIs You Won't Hate
apisyouwonthate.com · Personal blog · on HN since 2016
A site on API design and tooling, including REST, GraphQL, OpenAPI, and versioning, with a book called Build APIs You Won't Hate.
What HN saysHN commenters recommend the site and its book as a good introduction to REST API design, and cite its posts on OpenAPI generation.
19HN people shared it
6linked it in comments
20stories submitted
362story points
1 year agolast shared
2016people per year2026
Most-shared posts
- 1API versioning has no “right way” (2017)2 people · 135 points · first shared 2020 · 56 comments on HN
- 2OpenAPI v3.1 and JSON Schema 2019-092 people · 90 points · first shared 2020 · 45 comments on HN
- 3Content to Supplement Your API Documentation2 people · 3 points · first shared 2023 · discussion on HN
- 4REST and Hypermedia in 20192 people · 2 points · first shared 2020 · discussion on HN
- 5PKCE vs. Proxy2 people · 2 points · first shared 2019 · discussion on HN
- 6Homepage2 people · first shared 2016
- 7Let's stop building APIs around a network hack (2017)1 people · 105 points · first shared 2020 · 94 comments on HN
- 8GraphQL and Caching1 people · 12 points · first shared 2019 · 5 comments on HN
- 9API Design-First vs. Code First1 people · 2 points · first shared 2019 · discussion on HN
- 10Oracle Shuts Down Apiary.io1 people · 2 points · first shared 2025 · discussion on HN
- 11Representing State in REST (Roy Fielding) and GraphQL1 people · 2 points · first shared 2019 · discussion on HN
- 12Civic APIs1 people · 2 points · first shared 2025 · 1 comments on HN
- 13Layoffs at Postman1 people · 2 points · first shared 2024 · 1 comments on HN
- 14Generate a TypeScript REST API Client with Fern1 people · 1 points · first shared 2023 · discussion on HN
- 15There's No Reason to Write OpenAPI by Hand1 people · 1 points · first shared 2022 · 1 comments on HN
What HN people wrote when they linked it
shivenigma · 2020-09-11
for REST APIs, https://apisyouwonthate.com/books/build-apis-you-wont-hate book is my recommendation if you haven't read it already. I read it as a beginner, so it was kind of an eye opener for me on why we should do things a certain way when it comes to API.
mordocai · 2016-08-10
I thought https://apisyouwonthate.com/ was pretty good, assuming REST API.
jeanyang · 2022-07-06
Hi, Jean here from Akita. Yes, it's possible to generate an OpenAPI spec, either by running Akita in production or from a HAR file. Here's a blog post someone wrote about using Akita to generate an OpenAPI spec: https://apisyouwonthate.com/blog/creating-openapi-from-http-traffic
psturgeon · 2021-05-02
The whole "REST is good and everything else is dumb" is something I've tried to help people get away from for about a decade. These days it's GraphQL is good and everything else is dumb. See some of the comments in here.
> I wish anything built on REST would die. Conflation of the envelope and the payload is idiotic and adds only pain, no value.
Anyway, a reasoned conversation about where REST can be useful even today: https://apisyouwonthate.com/blog/rest-and-hypermedia-in-2019
And a technical comparison for when people need it: https://apisyouwonthate.com/blog/understanding-rpc-rest-and-graphql
And when those technical differences can come in useful or just be annoying: https://apisyouwonthate.com/blog/picking-the-right-api-paradigm
Loooooots of content on all this. :)
majkinetor · 2020-09-05
https://apisyouwonthate.com and their book(s) offer good advices.
Not a book, but MS REST API Guidelines are pretty good although they don't cover funky important details like how to properly do REST operations/actions.
https://github.com/microsoft/api-guidelines
This is short one based on RedHat VM engineer experience:
https://restful-api-design.readthedocs.io/en/latest/intro.html
Manning has a solid books on topic:
https://www.manning.com/books/the-design-of-web-apis
https://www.manning.com/books/api-design-patterns
gautambt · 2020-07-08
Not a general solution, but with Hasura, one approach we have seen is to use Postgres views to keep the old graph around as your data model changes.
In general API evolution is tricky and perfect decoupling between API clients and servers not possible (the article talks about this). What one can aim for is a combination of:
1) Adding new query parameters should not break clients
2) Adding new fields to the responses should not break clients
3) Adding new serialization formats (for newer clients) should not break existing clients
#1 & #2 is roughly what you get with GraphQL optional fields.
Phil Sturgeon has good articles on API Versioning[1] and Evolvability[2] for REST API's
[1] https://apisyouwonthate.com/blog/api-versioning-has-no-right-way
[2] https://phil.tech/2018/api-evolution-for-rest-http-apis/