Simplicity wins
When we started building Blotd, we had a choice: REST or GraphQL. We picked REST, and here is why.
Our users want speed, not flexibility
GraphQL shines when you have complex, interconnected data and clients that need to cherry-pick exactly what they want. A blog API is not that. You fetch articles. Maybe filter by tag or search by keyword. The data shape is predictable and consistent.
REST gives you that with zero learning curve. Every developer knows how to make a GET request. No query language to learn, no schema to introspect, no client libraries required.
Caching is straightforward
REST endpoints map naturally to HTTP caching. Set a Cache-Control header and CDNs, browsers, and reverse proxies all know what to do. GraphQL's single endpoint makes caching significantly harder.
For a blog API where content changes infrequently but gets read constantly, this matters a lot.
Debugging is easier
When something goes wrong with a REST API, you open your browser's network tab, see the URL, see the response. With GraphQL, you are debugging query strings, checking variables, and reading through resolver chains.
The right tool for the job
GraphQL is excellent for applications with complex data requirements. But for a blog API that serves articles, tags, and search results, REST is the right choice. Simpler to build, simpler to use, simpler to cache.