None of it is REST though, it's just one more RPC over HTTP protocol, which is also what TFAA advertises. Though your version uses HTTP as more than a trivial transport which I guess is nice.
If this isn't REST then the Wikipedia page on REST needs updating or I'm just not explaining it well enough.
REST based on the Richardson maturity model[1] involves:
Level 0: Using HTTP as the transport protocol: e.g. SOAP
Level 1: Identifiable objects: e.g. /object/object_id
Level 2: Using HTTP as the application protocol: e.g. Using POST to create new objects and DELETE to remove them
Level 3: HATEOAS
[1] https://martinfowler.com/articles/richardsonMaturityModel.ht...
`/robots/robot_id/exceptions`
`/maps/map_id/destinations`
`/maps/map_id/areas/speed_limit_areas`
Performing operations is not done via. RPC but rather POSTing a new `mission` to the queue.
There's no HATEOS but that would generally be silly, since this isn't an API that requires easy discovery and consumption by third parties. I'm not sure I subscribe to the HATEOS required for REST, but I don't really care to argue.
I think I'm starting to get a sense that people can be really opinionated on this stuff, and I'm still lost as to what there is to gain by it. To suggest what I'm describing isn't REST would be to say that the first sections of the Wikipedia page are wrong. So are we so far off-base that we need to revise the Wikipedia page? Or is this more just an opinion?
Thanks for sharing your thoughts. Maybe there's a chance to de-mystify my confusion on why there's so many opinions on something that, to me, seems so simple to define.
Sadly the person you respond to is an idiot, their points 1 and 3 have literally nothing to do with REST. You could have all endpoints be /435645646 yet do rest, you can have the most beautifully crafted URLs in the world and do rpc, they're orthogonal concerns. Most people do the latter, incidentally.
> Performing operations is not done via. RPC but rather POSTing a new `mission` to the queue.
That's still RPC. Encoding your procedure calls via HTTP verbs doesn't make it not RPC, it makes it (as originally noted) leverage HTTP as more than a trivial transport.
> There's no HATEOS
So it's not REST, HATEOAS/hyperlinking is the one thing that qualifies your API as REST according to the bloke who originally defined that term: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
> I think I'm starting to get a sense that people can be really opinionated on this stuff
Well yeah imagine you see a nice essay defining or formalising a concept (hyperlinked application interfaces) and creating a word/acronym for it (REST), then you see the world around it coopt it without any of the meaning to qualify something which already existed but has seemingly fallen out of fashion (RPC in this case). That's bothersome.
> seems so simple to define.
If your simple definition of REST is just that you're using HTTP, why would you need a separate acronym for it?
"Somewhat misguided" is a lot less harsh and confrontational, FWIW. HN civility guidelines and all.
>> Performing operations is not done via. RPC but rather POSTing a new `mission` to the queue.
> That's still RPC. Encoding your procedure calls via HTTP verbs doesn't make it not RPC, it makes it (as originally noted) leverage HTTP as more than a trivial transport.
RPC uses POST, and sometimes GET, usually to a single URL. OP is creating, modifying, and deleting resources, each at its own URL, using the proper HTTP verbs. You might be getting hung up on the fact that the "mission" resource corresponds to something conceptual rather than something physical like an individual robot? Again, that's your own taste, rather than anything about REST. Or do you mean instead that OP should invent some new verbs appropriate to robots, like MOVE or ACTUATE? That would be a bit goofy...
NRRESTBTGTTERM.
Hmm, that doesn't really roll off the tongue. Maybe BetterREST.
It's not better and it still is not REST.
Why don't you just call it what it is: HTTP. Or maybe HTTP-RPC if you want to be more specific.
The reasons I have against it are that
1. I think it complicates the client because it needs to discover the api at runtime instead of just coding it up in a straight forward manner.
2. Receiving the capabilities seems to imply that these are the activities that can succeed. But they don't have to succeed. So you still have to handle errors. So you may as well know up front what the whole API is and handle errors, etc.
3. Dynamic apis are resistant to pipelining if you don't know what the next url will be.
But I'm here to learn, so please hit me with a clue stick and explain why REST sans HATEOAS is not better.
To be more specific, HATEOAS is an essential component to comply with the Uniform Interface constraint of REST, which, as the dissertation describes, allows for decoupling and independent evolvability of the client and server.
Since we still accept the idea that client libraries and the programs that use them should be completely coupled with the services they communicate with, and it's fine to force thousands or millions of developers to update their software because an URL on some service changed, HATEOAS doesn't feel particularly useful.
You mean like Electron applications? :P
But seriously, I don't know what kind of clients you want to use, but if I want to store data on an object store, for example, I know what the verbs are. And if a new one is added, then at some point I need to change something on the client side to factor that in. Unless the server is also serving the UI as they do with web pages.
<semi-rhetorical-strawman>If I'm using something like $AccountingProgram and my bank puts in a new possible action like "donate" to let me easily donate to charities which will return important information like deductions and the relevant fields, etc., then how might my accounting become aware of this new concept? </semi-rhetorical-strawman>.
Maybe I'm too troglodyte to see it. My engineering senses are tingling with excitement that it would be cool that it automatically gets through to the client (without also being open to click/UI hijacking from shitheads) but I just don't see how it can happen.
Still happens all the time in mobile world. Not as obvious in Desktop word because the site is the app, you just download it each time anew instead of once. But there are Chrome plugins for many sites - Chrome web store has a lot of them. Most of the sites can work fine without them, nevertheless they exist.
Huh. What does this abbreviation mean in this context? I'm at a total loss here, and the only relevant google result is this thread.