> GraphQL I think is meeting a similar need but with the added advantage that it was designed for the task at hand, mostly not by a committee.
Right on. I think that its early strength of opinion and design and having a spec available from the get-go is one of GraphQL's big strengths.
There are lots of ideas about how to use REST and HTTP correctly, but for the most part the only things that are universally agreed on are that URLs are _usually_ resources (you can find lots of cases where they're not even in APIs that are popularly thought to be well designed) and that HTTP verbs _should_ map to CRUD (but again, they often don't because ideas like `PATCH` only became widespread quite late in the game).
Right on. I think that its early strength of opinion and design and having a spec available from the get-go is one of GraphQL's big strengths.
There are lots of ideas about how to use REST and HTTP correctly, but for the most part the only things that are universally agreed on are that URLs are _usually_ resources (you can find lots of cases where they're not even in APIs that are popularly thought to be well designed) and that HTTP verbs _should_ map to CRUD (but again, they often don't because ideas like `PATCH` only became widespread quite late in the game).