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.
> 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.
> 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].
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
> 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.
