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

151–160 of 224 posts

Re: Problems with RESTful APIs (2015)

#151

Post by [deleted] »

LoSboccacc wrote: post #88
rantanplan wrote: post #4

Earlier quoted context omitted.

> I've been trying hard for years to find a reason to bother with PUT, but so far I've found it not worth the effort. And right there, at your final sentence, you basically described why REST has more or less failed. GET and POST are useless for implementing a complete application protocol. You'd basically overload these http verbs to the point where you would implement your own protocol. And that's what most people…

Rest is a well defined semantic everybody bastardized because they find shameful to say they use json-rpc on the resume or elsewhere. There's a difference there.

[deleted]

Re: Problems with RESTful APIs (2015)

#152

Post by jondubois »

The author seems supportive of the core principles behind REST but arguing against its specific implementation in HTTP.

I wrote a related article for Hacker Noon a few days ago which was trending on Reddit: https://hackernoon.com/rest-over-websockets-instead-of-http-...

It's interesting that an increasing number of developers are pushing the notion of using REST-like ideas over WebSockets instead of HTTP.

Re: Problems with RESTful APIs (2015)

#153

Post by fdsak »

u801e wrote: post #90
robzhu wrote: post #72

Like other posters have said, the author appears to be pointing out shortcomings with HTTP, not REST. Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints: https://en.wikipedia.org/wiki/Representational_state_transfe... . Anything that meets these constraints is considered "REST". Most of the constraints sound like common…

> Roy Fielding made it fairly clear that REST is not strictly associated with HTTP. REST, as an architectural style, is defined by a set of constraints: Out of curiosity, do you know of any examples of RESTful APIs that use a protocol other than HTTP (say like IMAP or NNTP)?

That is the the real test beyond technical jargon and If someone provides a working example that works over different protocols as you have suggested that will be end of discussion :)

Re: Problems with RESTful APIs (2015)

#154

Post by rantanplan »

naasking wrote: post #49
rantanplan wrote: post #4

Earlier quoted context omitted.

> I've been trying hard for years to find a reason to bother with PUT, but so far I've found it not worth the effort. And right there, at your final sentence, you basically described why REST has more or less failed. GET and POST are useless for implementing a complete application protocol. You'd basically overload these http verbs to the point where you would implement your own protocol. And that's what most people…

> As the article points out, there are all too many HTTP libraries that only support GET and POST, not the more "esoteric" verbs like PUT and DELETE. GET and POST are all you need: "Return representation of available operations" and "apply this operation". It's the lambda calculus applied to the web (see Waterken's web-calculus for a more formal treatment). You might say that this is too anemic a foundation and you w…

You're just supporting my argument and weakening REST's case.

I can do you one better. If you managed to reduce everything down to GET and POST here's an idea; just use POST for everything. Boom. You just re-invented SOAP.

Re: Problems with RESTful APIs (2015)

#155

Post by jgalt212 »

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…

You've basically implemented ReST: The Good Parts

Can someone write this pamphlet?

Re: Problems with RESTful APIs (2015)

#156

Post by dahauns »

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.

> TFAA

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.

Re: Problems with RESTful APIs (2015)

#157

Post by k__ »

beachy wrote: post #60

This article is largely bollocks. 1) Almost every gripe in it refers to bad implementations, not bad specs. 2) It doesn't even mention HATEOAS. I'm no fan, but usually arguments about whether your API is REST or not revolve around how/whether you've done HATEOAS. 3) The rest of it is pulp tech writing that sounds like it was vomited out to meet some kind of publishing deadline. Case in point: > Consider, for example,…

I thought REST didn't define much so basically every API can be REST conform.

Just because HATEOAS makes REST APIs better, doesn't mean those without the use of it aren't REST.

Even SOAP can be REST conform.

Anyway, I guess with the rise of GraphQL, which is more strict (at least in its definition) REST will go away and we will have better dev life's.

Re: Problems with RESTful APIs (2015)

#158

Post by [deleted] »

beachy wrote: post #60

This article is largely bollocks. 1) Almost every gripe in it refers to bad implementations, not bad specs. 2) It doesn't even mention HATEOAS. I'm no fan, but usually arguments about whether your API is REST or not revolve around how/whether you've done HATEOAS. 3) The rest of it is pulp tech writing that sounds like it was vomited out to meet some kind of publishing deadline. Case in point: > Consider, for example,…

[deleted]

Re: Problems with RESTful APIs (2015)

#159

Post by tjpnz »

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…

> But over time numerous people started told me that no it's actually all wrong for one reason or another. I've heard that I should never use anything except GET and POST.

I used to work for a place where people said exactly that. It was then followed with comments that anything other than GET and POST posed a security risk.

There's still a staggering amount of ignorance out there of HTTP; even amongst those who claim to be web developers.

Re: Problems with RESTful APIs (2015)

#160

Post by martin-adams »

beachy wrote: post #109
imafish wrote: post #96

> most client and server applications don’t support all verbs or response codes for the HTTP protocol. For example, most web browsers have limited support for PUT or DELETE. And many server applications often don’t properly support these methods either. I have never, as in ever, stumbled upon this problem. So I googled it. It turns out that what he means is that HTML forms don't support PUT and DELETE. In a world whe…

To be fair, the verbs can feel a little weird. GET is easy. HEAD is easy. DELETE is easy. PATCH is easy, especially when you use one of the two more useful standards (RFC 7386: JSON Merge Patch, or RFC 6902: JSON Patch). PUT is not much use for large resources (like those typically found in business systems) since it requires you to provide every field, but usually you would want the back end to assign at the last th…

When you say you want the server to assign the identifier and additional fields, then I guess this would be considered read-only metadata against the resource. I don't recall seeing anything stating that in my RESTful travels.
Post reply on HN