Re:Ask HN: Is it time for a REST specification?
by daliwali on Thursday July 20, 2017 @02:30PM
(#14815104)
No one is stopping you from implementing a URL like: `/feed?include=users`, which is easier on the eyes than the GraphQL equivalent. But clients generally aren't aware of the `include` query or what it does unless it's advertised from the server. There's URI templates (RFC 6570) which let you advertise it as `/feed{?include}`, but few clients understand URI templates. With GraphQL, it's part of the spec, but you must know that the server follows the spec anyways.
Re:Ask HN: Is it time for a REST specification?
by ahoka on Friday July 21, 2017 @03:06AM
(#14818631)
What's the point of discoverability when consumers don't know the semantic meaning? Does it help if you discover that you can add an include query? That you can pass the value "user"? What is a user? Maybe you can look it up in Swagger. Is that still discoverable? What if it needs more than just common sense to understand the business language?
Re:Ask HN: Is it time for a REST specification?
by daliwali on Friday July 21, 2017 @11:03AM
(#14821077)
That's what a vocabulary is for. schema.org[0] has something semantically equivalent to a user, a person.
Re:Ask HN: Is it time for a REST specification?
by ruslan_talpa on Thursday July 20, 2017 @02:41PM
(#14815193)
This is exactly what PostgREST is doing, it's interface has the same expressive power as GraphQL
https://trends.google.com/trends/explore?date=today%205-y&q=...
If you were building a large scale API now, having duplicate data at each resource (eg, avatar icon URLs in /feed) or requiring users to cross reference multiple resources for a single simple task (eg GETing /users and /feed to draw a simple timeline with user avatars) is a hassle and there's no real reason to force yourself or your API consumers through it.
The GraphQL specification is here: https://facebook.github.io/graphql/