3 ms·
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 d
by eicnix 10y ago
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.html https://martinfowler.com/articles/richardsonMaturityModel.ht...
- Waterluvian 10y agoI'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.
- masklinn 10y ago> 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-hypertext-driven 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?
- deckiedan 10y ago> Sadly the person you respond to is an idiot, "Somewhat misguided" is a lot less harsh and confrontational, FWIW. HN civility guidelines and all.
- deleted 10y ago[deleted]
- deleted 10y ago[deleted]
- jessaustin 10y agoI'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...