3 ms·

Most (or all?) of those are GraphQL rather than REST.

masklinn 6y ago
Given that, despite the project name, the tool described by TFA is pretty obviously RPC over HTTP rather than anything resembling Fielding's description, graphql would would just as well.
- michelpp 6y ago
  Sorry but I disagree, PostgREST is REST. For example URLs map to resources and it uses HTTP verbs. GraphQL does not.
  - masklinn 6y ago
    > Sorry but I disagree Feel free to. But maybe consider that "taking advantage of HTTP" != "REST". > PostgREST is REST. The primary if not sole distinction of a REST system according to the creator of the concept is hyperlinking. From what I understand of postgrest, hyperlinking is nonexistent. > For example URLs map to resources Which doesn't really matter when these URLs are magic strings. It's also not really true, URLs are a mix of procedures (/tsearch, literally everything below /rpc) and function names, really, to be passed a bundle of parameters through query strings. And the project itself recommends using stored procedures (and views) when exposing the system to any sort of untrusted environments. > it uses HTTP verbs Not actually relevant to REST, and serving as little more than a form of namespacing.
    - steve-chavez 6y ago
      > URLs are a mix of procedures (/tsearch, literally everything below /rpc) and function names Perhaps you'd be surprised in knowing that a resource can be a stored procedure, quoting Roy Fielding[1]: "a single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items" In general I think PostgREST's REST implementation is evolving. Also, we've had Roy Fielding giving feedback[2] on an issue before. Once we fix that issue, we'll ask him if he thinks if PostgREST is REST. I have a feeling that he might reply positively :-]. We'll see. [1]:https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... [2]: https://github.com/PostgREST/postgrest/issues/1089#issuecomment-515184613 https://github.com/PostgREST/postgrest/issues/1089#issuecomm...
      - masklinn 6y ago
        > Perhaps you'd be surprised in knowing that a resource can be a stored procedure, quoting Roy Fielding[1]: I'll direct you to the title of the post to which this comment is associated. >> REST APIs must be hypertext-driven > I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Now maybe I missed all the hypertext in postgrest, but given all of its documentation obviously fails the criteria of > A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). I don't see how it could be in any way REST. > Also, we've had Roy Fielding giving feedback[2] on an issue before. That is feedback on an issue of HTTP implementation and compliance, it has nothing to do with REST. Now look I really don't mind APIs being good HTTP citizens and having nothing to do with hypermedia, and that REST is an interesting idea doesn't mean it's a good idea (at least for programmatic APIs). But it's like people saw a picture of a baby in a bath, went "well I don't need the pink thing in the middle but I'd sure like to wash up a bit", and when others point out they're carrying around a jug of soapy water which they insist is a baby called Fred those others get called "Baby purists"[-1]. [-1] https://news.ycombinator.com/item?id=25171460 https://news.ycombinator.com/item?id=25171460
        np_tedious 6y ago
        This sort of proves the point though, doesn't it? REST as initially defined has become some kind of hyperlinked / referenced platonic ideal that very few do or even attempt. Postgrest, returning/modifying predefined resource(s) based on standard HTTP verbs and whatnot, is at least as RESTful as most other things that use the term. Despite the imprecision, this is still a somewhat useful descriptor beyond "oh it's arbitrary RPC". And it's not at all like GraphQL
        masklinn 6y ago
        > This sort of proves the point though, doesn't it? It definitely proves that postgrest is not rest in any way. > REST as initially defined has become some kind of hyperlinked / referenced platonic ideal that very few do or even attempt. Sure? At no point have I been arguing for doing REST. Just for not calling things REST when they obviously are not? > Postgrest, returning/modifying predefined resource(s) based on standard HTTP verbs and whatnot, is at least as RESTful as most other things that use the term. While I completely agree that PostgREST's qualifier is entirely as worthless as every other thing calling itself REST, I don't think that's praiseworthy. > Despite the imprecision It's not imprecision, it's actively lying. It doesn't do what it says on the tin, and the tin doesn't describe what it actually do. REST is an actual acronym, not an arbitrary trademark, it stands for words which have meaning.
xgenecloud 6y ago
XgeneCloud[1] supports REST as well. https://github.com/xgenecloud/xgenecloud https://github.com/xgenecloud/xgenecloud

Given that, despite the project name, the tool described by TFA is pretty obviously RPC over HTTP rather than anything resembling Fielding's description, graphql would would just as well.

michelpp 6y ago
Sorry but I disagree, PostgREST is REST. For example URLs map to resources and it uses HTTP verbs. GraphQL does not.
- masklinn 6y ago
  > Sorry but I disagree Feel free to. But maybe consider that "taking advantage of HTTP" != "REST". > PostgREST is REST. The primary if not sole distinction of a REST system according to the creator of the concept is hyperlinking. From what I understand of postgrest, hyperlinking is nonexistent. > For example URLs map to resources Which doesn't really matter when these URLs are magic strings. It's also not really true, URLs are a mix of procedures (/tsearch, literally everything below /rpc) and function names, really, to be passed a bundle of parameters through query strings. And the project itself recommends using stored procedures (and views) when exposing the system to any sort of untrusted environments. > it uses HTTP verbs Not actually relevant to REST, and serving as little more than a form of namespacing.
  - steve-chavez 6y ago
    > URLs are a mix of procedures (/tsearch, literally everything below /rpc) and function names Perhaps you'd be surprised in knowing that a resource can be a stored procedure, quoting Roy Fielding[1]: "a single resource can be the equivalent of a database stored procedure, with the power to abstract state changes over any number of storage items" In general I think PostgREST's REST implementation is evolving. Also, we've had Roy Fielding giving feedback[2] on an issue before. Once we fix that issue, we'll ask him if he thinks if PostgREST is REST. I have a feeling that he might reply positively :-]. We'll see. [1]:https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-743 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert... [2]: https://github.com/PostgREST/postgrest/issues/1089#issuecomment-515184613 https://github.com/PostgREST/postgrest/issues/1089#issuecomm...
    - masklinn 6y ago
      > Perhaps you'd be surprised in knowing that a resource can be a stored procedure, quoting Roy Fielding[1]: I'll direct you to the title of the post to which this comment is associated. >> REST APIs must be hypertext-driven > I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Now maybe I missed all the hypertext in postgrest, but given all of its documentation obviously fails the criteria of > A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). I don't see how it could be in any way REST. > Also, we've had Roy Fielding giving feedback[2] on an issue before. That is feedback on an issue of HTTP implementation and compliance, it has nothing to do with REST. Now look I really don't mind APIs being good HTTP citizens and having nothing to do with hypermedia, and that REST is an interesting idea doesn't mean it's a good idea (at least for programmatic APIs). But it's like people saw a picture of a baby in a bath, went "well I don't need the pink thing in the middle but I'd sure like to wash up a bit", and when others point out they're carrying around a jug of soapy water which they insist is a baby called Fred those others get called "Baby purists"[-1]. [-1] https://news.ycombinator.com/item?id=25171460 https://news.ycombinator.com/item?id=25171460
      - np_tedious 6y ago
        This sort of proves the point though, doesn't it? REST as initially defined has become some kind of hyperlinked / referenced platonic ideal that very few do or even attempt. Postgrest, returning/modifying predefined resource(s) based on standard HTTP verbs and whatnot, is at least as RESTful as most other things that use the term. Despite the imprecision, this is still a somewhat useful descriptor beyond "oh it's arbitrary RPC". And it's not at all like GraphQL
        masklinn 6y ago
        > This sort of proves the point though, doesn't it? It definitely proves that postgrest is not rest in any way. > REST as initially defined has become some kind of hyperlinked / referenced platonic ideal that very few do or even attempt. Sure? At no point have I been arguing for doing REST. Just for not calling things REST when they obviously are not? > Postgrest, returning/modifying predefined resource(s) based on standard HTTP verbs and whatnot, is at least as RESTful as most other things that use the term. While I completely agree that PostgREST's qualifier is entirely as worthless as every other thing calling itself REST, I don't think that's praiseworthy. > Despite the imprecision It's not imprecision, it's actively lying. It doesn't do what it says on the tin, and the tin doesn't describe what it actually do. REST is an actual acronym, not an arbitrary trademark, it stands for words which have meaning.

xgenecloud 6y ago

XgeneCloud[1] supports REST as well. https://github.com/xgenecloud/xgenecloud https://github.com/xgenecloud/xgenecloud