Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Problems with RESTful APIs (2015)

mmikowski.github.io

Post reply on HN
Print view View original

111–120 of 224 posts

Re: Problems with RESTful APIs (2015)

#111

Post by masklinn »

codr4life wrote: post #31
andybak wrote: post #5

Earlier quoted context omitted.

What you just described is only the bare shell of REST. It would also apply to many types of API that don't follow REST principles. One thing this article gets right is that nobody is really RESTful because nobody knows what it means. There's usually a dollop of RPC in most APIs - and there's nothing wrong with that - but the 'pure vision' of REST is similar to the 'pure vision' of the Semantic Web. It's a dream for…

I'm fine with using ideas that make sense and rejecting the ones that don't. It's still solid advice for API design, and the most successful approach we've come up with. Doing REST to the letter always turns into some kind of modern art installation with lots of hammers looking for nails; this is the technology department, religion is down the corridor. I have full confidence that the authors considered these ideas,…

So… why do you call it REST rather than just HTTP since that's exactly what it is? You're using GET and POST for what they were built for, great, that's just HTTP, why not call it that?

> I have full confidence that the authors considered these ideas, not laws.

"The authors" considered hyperlinking to be the one core concept of REST, all the rest is just fluff/transport concerns: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte... (that's the bloke who wrote the original REST paper).

That's like saying the authors of the word "bicycle" considered it being two wheeled idea, not law, and you'll call your 8-wheeled ATV a bicycle because it has wheels and you think wheels are nice and solve your problem and the religion department is down the corridor.

Yeah wheels are nice and solve your problem, your motorised monstrosity is not a bicycle though.

Re: Problems with RESTful APIs (2015)

#112

Post by cwilkes »

tobyjsullivan wrote: post #65

On first pass, I totally agree with the author. I haven't reviewed the proposed alternative yet but fingers crossed. That said, I think he misses the single biggest issue with REST APIs that I continuously encounter and which has caused me to consider them sub-par. Representative "State" Transfer. REST APIs are only good for transferring around the state of stateful objects. However, CRUD operations are only part of…

I'm not sure what you mean by saving that microservices avoid state altogether vis a vis REST.

Re: Problems with RESTful APIs (2015)

#113

Post by deckiedan »

masklinn wrote: post #110
Waterluvian wrote: post #107

Earlier quoted context omitted.

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 b…

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

> Sadly the person you respond to is an idiot,

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

Re: Problems with RESTful APIs (2015)

#114

Post by INTPenis »

I've developed both REST and XMLRPC API's. The right tool for the right job.

Sometimes REST is that tool.

I also tend to combine JSON with REST. I still enjoy using proper HTTP codes when possible. So if you're sending a json payload to update an object that doesn't exist I'll give you 404. But at the same time you're able to create that object by defining its properties in a json payload in the next request and not some obscure url parameters or POST parameters.

I don't see anything wrong with using proper HTTP methods and return codes when possible.

Re: Problems with RESTful APIs (2015)

#116

Post by kowdermeister »

Waterluvian wrote: post #94

When I was given the task of defining how our multi-robot server would interface with our user interfaces, I eventually settled on REST. Most of what I knew about REST had been obtained that week. I implemented something pretty vanilla with Django and it all felt pretty elegant. I didn't have to worry about defining a protocol, there was pretty much already one for me: - GET, PUT, POST, DELETE (I learned there were o…

> - GET, PUT, POST, DELETE (I learned there were others but were kind of niche/obsolete) > - 200s for success, 400s for client (request) error, 500s for server error.

You did good job there. Ignore naysayers just because then they have to do more work to handle your correct error codes and actually send correct HTTP methods.

Re: Problems with RESTful APIs (2015)

#117

Post by [deleted] »

masklinn wrote: post #110
Waterluvian wrote: post #107

Earlier quoted context omitted.

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 b…

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

[deleted]

Re: Problems with RESTful APIs (2015)

#118

Post by fnord123 »

masklinn wrote: post #101
Waterluvian wrote: post #94

When I was given the task of defining how our multi-robot server would interface with our user interfaces, I eventually settled on REST. Most of what I knew about REST had been obtained that week. I implemented something pretty vanilla with Django and it all felt pretty elegant. I didn't have to worry about defining a protocol, there was pretty much already one for me: - GET, PUT, POST, DELETE (I learned there were o…

> I feel like I had success because I approached it from a position of ignorance, meaning I just implemented a simple, sane REST API and was none the wiser that I was doing it wrong. 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.

We need a name for it then. Like NotReallyRESTButTheGoodThingThatEveryoneReallyMeans.

NRRESTBTGTTERM.

Hmm, that doesn't really roll off the tongue. Maybe BetterREST.

Re: Problems with RESTful APIs (2015)

#120

Post by kowdermeister »

eranation wrote: post #73

Sorry for the controversial question, and I probably raised my eyebrow if I saw a candidate choose XML over JSON when taking on a recent project... but really, why JSON? No comments, no multiline, no schema. I understand that XML is bad because ____ (not cool, verbose, old school, only enterprises use it?) I am not a huge YAML fan but it seems this is the only human readable form of JSON. The lack of self describing…

> but really, why JSON? No comments, no multiline, no schema

Limitations are good. I find it really easy to read. You can install browser extensions to make it even more readable.

Schema can come from a well written specification.

> Was ditching XML for JSON just due to cosmetic / trending reasons?

No, as said before, it's easy to write / read / generate / parse. No awkward DOM style management if you want to parse out a value. I really hated it with XML.

HTML is fine also for what it was invented for.

Post reply on HN