Roy Fielding's Misappropriated REST Dissertation

Re:Roy Fielding's Misappropriated REST Dissertation by WClayFerguson on Monday June 29, 2020 @02:41PM (#23680872)

I consider HTTP the 'pipe' over which the data is marshalled. It has it's own error codes, it's own verbs, and it's own protocol that has nothing whatsoever to do with my API for my APP and that's the way I want to keep it.

I do an HTTP "post" to send up a JSON object as a request, and I get a JSON object back as the reply. No one is going to tell me there's a "simpler" way. There isn't.

For example, if I need to delete data, I'll call "deleteSomething" as an endpoint. I could care less if HTTP has a delete in it's language, because I don't want/need any of that coupled into my API or affecting my API in any way whatsoever.

That way my API can be moved to some non-HTTP pipe at some point and it will remain unchanged. It's just like how in good OOP you ideally code to 'interfaces' rather than coding to 'objects' directly.

Here's an example controller: https://github.com/Clay-Ferguson/quantizr/blob/master/src/ma...

You can tell it's perfectly type-safe on both client (TypeScript) and server (Java), and the API itself doesn't have any clue it's even be running over HTTP, and that's a good thing.

[ Parent | on HN ]

Re:Roy Fielding's Misappropriated REST Dissertation by dragonwriter on Monday June 29, 2020 @09:37PM (#23685584)

I'm not sure what your point is. Yes, RPC over HTTP post is a perfectly valid style of API. It's not REST. It may in some sense be simpler, but being simple for a narrow interface isn't the hallmark of REST (being simple on an “across a whole world wide network of diverse resources that don't share common ownership and control” is more REST’s thing.)

[ Parent | on HN ]

Re:Roy Fielding's Misappropriated REST Dissertation by WClayFerguson on Tuesday June 30, 2020 @06:42PM (#23695647)

My entire discussion has been around the assumption that there's some very specific WebApp that needs to communicate to a server (likely over HTTP too), and that I like RPC and verbs in my API.

What you seem to be stating is that there's more to that on the web and that HTTP has a reason to exist. I agree. It makes sense for the language of the browser itself to be basic CRUD-type calls to servers (which is what HTTP is)

But for a specific RPC interface for a specific WebApp client, trying to meld THAT API into HTTP (the goal of REST) is awkward as all hell and that IS what everyone's using it for.

[ Parent | on HN ]