5 ms·

That can easily be achieved by not following REST so strictly.

zten 10y ago
Naming and formatting it differently is an easy way to get away from the REST dogma, though.
nine_k 10y ago
Verily! GraphQL is one way to do just that. REST has the virtues of uniformity and discoverability. I don't yet understand whether GraphQL possesses any of these too, though.
- ec109685 10y ago
  Can you provide standardized examples of REST's uniforms toy and discoverability?
  - debaserab2 10y ago
    https://spring.io/understanding/HATEOAS https://spring.io/understanding/HATEOAS
    - dkersten 10y ago
      Its worth nothing that Roy Fielding, the guy who coined the term REST, doesn't consider an API RESTful unless it implements HATEOAS. At least, that's what he said in some talk I watched sometime ago.
      - SEJeff 10y ago
        He doesn't consider an API restful unless it is a hypermedia api, of which HATEOAS is an excellent example of.
- sametmax 10y ago
  In theory yes, in practice, I never saw REST discoverability being used much IRL
  - yen223 10y ago
    GraphQL puts discoverability front and centre, by prioritizing introspection and static typing. GraphiQL (the browser-based GraphQL explorer) is pretty hard to beat. Check out Github's GraphQL explorer for a great example of this: https://developer.github.com/early-access/graphql/explorer/ https://developer.github.com/early-access/graphql/explorer/
  - SEJeff 10y ago
    Because 90% of the "REST" developers don't actually build hypermedia apis, so they aren't really "REST" if you denote "REST" as somewhat complies with Roy Fielding's paper where he invented the acronym REST
dragonwriter 10y ago
Actually, it can easily be achieved by following REST strictly, especially the part where the key part of REST API design is selecting resources and designing appropriate representations for the intended use. "REST" as consistently and independent of use case a trivial CRUD layer over base tables is...well, almost as from actual REST as the JSON-based RPC over HTTP version of "REST".
- ec109685 10y ago
  Sorry, can you provide examples of deeply nested result hierarchies that are expressed well with Rest?
  - debaserab2 10y ago
    I find that if I'm having to deeply nest result hierarchies into my REST payload I probably haven't spent a lot of time thinking about how the API I am building will be consumed. Usually designing my endpoints to align more closely with the concepts consumers of the API expect prevents the need to nest a lot of data. You may have to break your endpoints away from your data structures somewhat and reorganize your API into the logical structures that more closely represent the way interactions are performed in your software. That's not to discount GraphQL, because I think it clearly has it's use cases, especially at Facebook size.
  - mhotchen 10y ago
    I use JSON API which allows for "compound documents" instead of deeply nested results[1]. I would say it's well expressed, and it doesn't violate any of the principles of REST. [1] http://jsonapi.org/format/#document-compound-documents http://jsonapi.org/format/#document-compound-documents
  - lh7 10y ago
    I am not sure I follow the conversation. What would a deeply nested result hierarchy be, exactly? Are we talking about something like: CREATE TABLE person (id INT, name TEXT, birthdate DATE); CREATE TABLE car (id INT, brand TEXT, model TEXT, licence TEXT); CREATE TABLE p_c (pid INT, cid INT, FOREIGN KEY pid REFERENCES person (id), FOREIGN KEY cid REFERENCES car (id)); And for a given person, we want to return their details plus the cars they own? gopher://example.com/person/{id} # Get person ID 1, Joe, 1970-01-01 gopher://example.com/car/{id} # Get car ID 1, Ford, T, 1313 gopher://example.com/person/{id}/cars # Get all cars owned by person ID 1, Joe, 1970-01-01, 1 Ford, T, 1313 ,,, 2 Ford, S, 1717 gopher://example.com/person/{id}/cars/{id} # Get specific car gopher://example.com/car/{id}/owners # Get owner(s) of car ID gopher://example.com/car/{id}/owners/{id} # Get specific owner gopher://example.com/car/{id}/owners/{id}/birthdate # Get specific owner's birthdate gopher://example.com/car/{id}/owners/birthdate # Get birthdate of all owners (assuming no domain overlap between IDs and field names, other solutions possible otherwise) If this is the sort of thing we're talking about, I've got that t-shirt and assumed everyone had too, so I guess I'm missing the point here. By how much?

zten 10y ago

Naming and formatting it differently is an easy way to get away from the REST dogma, though.

Verily! GraphQL is one way to do just that. REST has the virtues of uniformity and discoverability. I don't yet understand whether GraphQL possesses any of these too, though.

ec109685 10y ago
Can you provide standardized examples of REST's uniforms toy and discoverability?
- debaserab2 10y ago
  https://spring.io/understanding/HATEOAS https://spring.io/understanding/HATEOAS
  - dkersten 10y ago
    Its worth nothing that Roy Fielding, the guy who coined the term REST, doesn't consider an API RESTful unless it implements HATEOAS. At least, that's what he said in some talk I watched sometime ago.
    - SEJeff 10y ago
      He doesn't consider an API restful unless it is a hypermedia api, of which HATEOAS is an excellent example of.
sametmax 10y ago
In theory yes, in practice, I never saw REST discoverability being used much IRL
- yen223 10y ago
  GraphQL puts discoverability front and centre, by prioritizing introspection and static typing. GraphiQL (the browser-based GraphQL explorer) is pretty hard to beat. Check out Github's GraphQL explorer for a great example of this: https://developer.github.com/early-access/graphql/explorer/ https://developer.github.com/early-access/graphql/explorer/
- SEJeff 10y ago
  Because 90% of the "REST" developers don't actually build hypermedia apis, so they aren't really "REST" if you denote "REST" as somewhat complies with Roy Fielding's paper where he invented the acronym REST

dragonwriter 10y ago

Actually, it can easily be achieved by following REST strictly, especially the part where the key part of REST API design is selecting resources and designing appropriate representations for the intended use. "REST" as consistently and independent of use case a trivial CRUD layer over base tables is...well, almost as from actual REST as the JSON-based RPC over HTTP version of "REST".

ec109685 10y ago
Sorry, can you provide examples of deeply nested result hierarchies that are expressed well with Rest?
- debaserab2 10y ago
  I find that if I'm having to deeply nest result hierarchies into my REST payload I probably haven't spent a lot of time thinking about how the API I am building will be consumed. Usually designing my endpoints to align more closely with the concepts consumers of the API expect prevents the need to nest a lot of data. You may have to break your endpoints away from your data structures somewhat and reorganize your API into the logical structures that more closely represent the way interactions are performed in your software. That's not to discount GraphQL, because I think it clearly has it's use cases, especially at Facebook size.
- mhotchen 10y ago
  I use JSON API which allows for "compound documents" instead of deeply nested results[1]. I would say it's well expressed, and it doesn't violate any of the principles of REST. [1] http://jsonapi.org/format/#document-compound-documents http://jsonapi.org/format/#document-compound-documents
- lh7 10y ago
  I am not sure I follow the conversation. What would a deeply nested result hierarchy be, exactly? Are we talking about something like: CREATE TABLE person (id INT, name TEXT, birthdate DATE); CREATE TABLE car (id INT, brand TEXT, model TEXT, licence TEXT); CREATE TABLE p_c (pid INT, cid INT, FOREIGN KEY pid REFERENCES person (id), FOREIGN KEY cid REFERENCES car (id)); And for a given person, we want to return their details plus the cars they own? gopher://example.com/person/{id} # Get person ID 1, Joe, 1970-01-01 gopher://example.com/car/{id} # Get car ID 1, Ford, T, 1313 gopher://example.com/person/{id}/cars # Get all cars owned by person ID 1, Joe, 1970-01-01, 1 Ford, T, 1313 ,,, 2 Ford, S, 1717 gopher://example.com/person/{id}/cars/{id} # Get specific car gopher://example.com/car/{id}/owners # Get owner(s) of car ID gopher://example.com/car/{id}/owners/{id} # Get specific owner gopher://example.com/car/{id}/owners/{id}/birthdate # Get specific owner's birthdate gopher://example.com/car/{id}/owners/birthdate # Get birthdate of all owners (assuming no domain overlap between IDs and field names, other solutions possible otherwise) If this is the sort of thing we're talking about, I've got that t-shirt and assumed everyone had too, so I guess I'm missing the point here. By how much?