3 ms·

REST APIs Are Obsolete

5 points by Liriel 4y ago

smt88 4y ago
I remember when GraphQL came out way back in 2012, and I really did think that we'd see fewer REST APIs. To this day, I've never seen one, inherited one, or met someone who uses them in production. I'm sure HN has some happy GraphQL users, and there are some big companies outside Facebook that use it, but it must still be a tiny fraction of all APIs at this point. Tooling and caching are certainly still a lot simpler with REST APIs, and the vast majority of projects just don't need the extra efficiency.
- capableweb 4y ago
  The only big one I can think of is GitHub, whose new API is GraphQL.
Juliate 4y ago
Isn't the core issue that some developers would like to have the magical solution that solves/answers all use cases? You don't design your APIs in a vacuum. You have use cases. You should have basic ones still. You build your API v0 against those use cases, not against your data model or your architecture. Then you _monitor_ usage, you _consult/discuss_ with your users to see how to refine/augment your API to better serve their needs. REST or anything else matters little, as long as you do the job: listen and understand your user needs (it doesn't happen only once) and adapt.
lem__21 4y ago
GraphQL is like trying to re-implement SQL interface for DBs. Maybe instead of going through that tough way of reinventing the wheel they should just connect to that dbs directly ;)
- smt88 4y ago
  > Maybe instead of going through that tough way of reinventing the wheel they should just connect to that dbs directly ;) There are already a few solutions that do this. It's not unsafe as long as you're using a DBMS with row-level security (like Postgres) and you have a reasonable query timeout (probably < 1s) to prevent DoS attacks.
asplake 4y ago
> If you want to display a single field from a particular resource you still have to fetch everything. And for nested resources you have to fetch them separately. Says who?
cryptos 4y ago
The article ignores the fact that you can have use case specific resources and/or views with REST, too. If you're only interested in a picture and a title from a book, you could crete a content type that includes just that. And advantage of this approach is, that you can tailor the database query to return just that, what is not directly possible at the abstraction level of GraphQL.

5 points by Liriel 4y ago

I remember when GraphQL came out way back in 2012, and I really did think that we'd see fewer REST APIs. To this day, I've never seen one, inherited one, or met someone who uses them in production. I'm sure HN has some happy GraphQL users, and there are some big companies outside Facebook that use it, but it must still be a tiny fraction of all APIs at this point. Tooling and caching are certainly still a lot simpler with REST APIs, and the vast majority of projects just don't need the extra efficiency.

capableweb 4y ago
The only big one I can think of is GitHub, whose new API is GraphQL.

Juliate 4y ago

Isn't the core issue that some developers would like to have the magical solution that solves/answers all use cases? You don't design your APIs in a vacuum. You have use cases. You should have basic ones still. You build your API v0 against those use cases, not against your data model or your architecture. Then you _monitor_ usage, you _consult/discuss_ with your users to see how to refine/augment your API to better serve their needs. REST or anything else matters little, as long as you do the job: listen and understand your user needs (it doesn't happen only once) and adapt.

lem__21 4y ago

GraphQL is like trying to re-implement SQL interface for DBs. Maybe instead of going through that tough way of reinventing the wheel they should just connect to that dbs directly ;)

smt88 4y ago
> Maybe instead of going through that tough way of reinventing the wheel they should just connect to that dbs directly ;) There are already a few solutions that do this. It's not unsafe as long as you're using a DBMS with row-level security (like Postgres) and you have a reasonable query timeout (probably < 1s) to prevent DoS attacks.

asplake 4y ago

> If you want to display a single field from a particular resource you still have to fetch everything. And for nested resources you have to fetch them separately. Says who?

cryptos 4y ago

The article ignores the fact that you can have use case specific resources and/or views with REST, too. If you're only interested in a picture and a title from a book, you could crete a content type that includes just that. And advantage of this approach is, that you can tailor the database query to return just that, what is not directly possible at the abstraction level of GraphQL.