Hacker News Reader

Comment by Waterluvian | Hacker News Reader

We read then manipulate the state of a multi-robot fleet by making HTTP GET, PUT, POST, DELETE calls that affect a database and robot broker/manager services. The state of the robots and the configuration of the system is represented in JSON. Interaction with the system is stateless, meaning you can jump in at any time, understand the full state of the system, and manipulate it safely. Interaction of a healthy system will involve numerous physical and virtual clients/servers, many of which are physically on the move most of the time.

If this isn't REST then the Wikipedia page on REST needs updating or I'm just not explaining it well enough.

View on HN

I agree that the communication you described isn't completely REST style but rather "just" using HTTP as an application protocol. There is no real downside in doing so but it shouldn't be called REST.

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

I'm not sure where I misguided people that I was just doing RPC. Almost all endpoints are as you described:

`/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.

> I'm not sure where I misguided people that I was just doing RPC.

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?

> Sadly the person you respond to is an idiot,

"Somewhat misguided" is a lot less harsh and confrontational, FWIW. HN civility guidelines and all.

I'm with you on HATEOS, but I suspect OP is selling OP's system a bit short, and you're filling in the blanks in the least charitable way. The resource at "/maps/map_id/destinations", for example, probably has links to particular destinations, and those destinations probably have e.g. "modify this destination" forms. You might prefer for the URL to be "/ab129f294b", but that is your own taste rather than anything about REST. There is nothing wrong with memorable URLs.

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

Reply on news.ycombinator.com