3 ms·

> By Betteridge's Law of Headlines, the answer is "No". I feel a little bad for phrasing a title like a question, but an alternative working title was "The Fut

by brandur 10y ago

> By Betteridge's Law of Headlines, the answer is "No". I feel a little bad for phrasing a title like a question, but an alternative working title was "The Future of API Paradigms". I tried to touch on a variety of possible paths beyond GraphQL, including that REST might be the right way forward. > REST describes the architecture of the web, which most websites already conform to. Developers could design web APIs more like web pages, but standard media types must be adopted first. JSON-LD is a strong contender at that. Yes, quite possible, but it seems to me that REST and hypermedia aren't actually buying us all that much when it comes to APIs. Theoretically it makes them more discoverable and future proof, but in practice I find that no one really uses these features, and even when they're available, they're often used improperly. On the other hand, something like GraphQL has some pretty significant advantages in the form of very flexible querying and very efficient message transport (you get everything in one call instead of _N_).

daliwali 10y ago
Having a specification that tells you exactly how to do a particular thing can be more expedient than being open to interpretation. But short-term benefits aren't exactly a goal of REST: >REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release. [0] There isn't anything about REST that is opposed to flexible querying or fetching multiple resources in one request. Isn't that what web pages do already? I've used very complicated search forms and fetched lots of related data on the same page. What makes it possible is the use of standards like query strings, x-www-urlformencoded, multipart/formdata, and HTML itself. Machine clients may just need their own media types. [0] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...

by brandur 10y ago

daliwali 10y ago

Having a specification that tells you exactly how to do a particular thing can be more expedient than being open to interpretation. But short-term benefits aren't exactly a goal of REST: >REST is software design on the scale of decades: every detail is intended to promote software longevity and independent evolution. Many of the constraints are directly opposed to short-term efficiency. Unfortunately, people are fairly good at short-term design, and usually awful at long-term design. Most don’t think they need to design past the current release. [0] There isn't anything about REST that is opposed to flexible querying or fetching multiple resources in one request. Isn't that what web pages do already? I've used very complicated search forms and fetched lots of related data on the same page. What makes it possible is the use of standards like query strings, x-www-urlformencoded, multipart/formdata, and HTML itself. Machine clients may just need their own media types. [0] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...