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

161–170 of 224 posts

Re: Problems with RESTful APIs (2015)

#161

Post by david-given »

dahauns wrote: post #156
masklinn wrote: post #101

Earlier quoted context omitted.

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

'The gently caressing article above'? Maybe? It's new to me, too.

Re: Problems with RESTful APIs (2015)

#163

Post by fnord123 »

masklinn wrote: post #126
fnord123 wrote: post #118

Earlier quoted context omitted.

We need a name for it then. Like NotReallyRESTButTheGoodThingThatEveryoneReallyMeans. NRRESTBTGTTERM. Hmm, that doesn't really roll off the tongue. Maybe BetterREST.

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

To be clear, I think we're talking about REST without HATEOAS. And I think this is better, imo, as you can write your client knowing the protocol. I've not come across a convincing description of why HATEOAS is a good thing at all. And I say this as someone who thinks capability based design is a good thing.

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.

Re: Problems with RESTful APIs (2015)

#164

Post by joncrocks »

int_19h wrote: post #146
naasking wrote: post #66

Earlier quoted context omitted.

It's not worth making the distinction between idempotent and non-idempotent writes given the possibility of network partitions. Every write must be made idempotent because all you can do is retry in this case. PUT is merely an optimization on idempotent POST requests, one that will become progressively rarer as HTTPS continues to spread. POST requests can be made idempotent by binding the result of processing that re…

An insert cannot be idempotent by the very definition of the operation.

It can be as long as you have some kind of identity information associated with the request, and provided alongside any requests that are the 'same'.

e.g. Instead of saying "Insert a transaction for £20", you say, "Insert a transaction that entity A calls 1234, for £20".

Stripe use something like this to ensure that as long as you call their API to ask for a payment and use the same key, they won't charge the person twice.

https://stripe.com/docs/api#idempotent_requests

Re: Problems with RESTful APIs (2015)

#165

Post by Mikhail_Edoshin »

SEJeff wrote: post #79
quanticle wrote: post #18

Earlier quoted context omitted.

The "true spirit" of REST, to me, is that there's a certain set of things you can do when creating an API that will let you re-use the huge amount of HTTP middleware that's been written and get correct (and useful!) semantics from it. Caches (browser-, edge-, and server-side-), load balancers, forward- and reverse-proxies, application-layer firewalls, etc. will all "just work" for your software if you do REST correct…

Or (for REST apis that might need concurrent updates of the same model) the most awesome "esoteric" verb, PATCH

Look into WebDAV and you'll find plenty :) LOCK, UNLOCK, COPY, MOVE, MKCOL, PROPFIND, PROPPATCH. And also REPORT, SEARCH, and various version-control operations.

Re: Problems with RESTful APIs (2015)

#166

Post by anentropic »

Mandatum wrote: post #61

I think the first comment/reply to the post hits the nail on the head, by Florian Klein[0]: > Awesome! You replaced REST with REST. How revolutionary: > Instead of transferring application state through the wire via one of its representations, > you know transfer its state through the wire via one of its representations. > Do I need to go any further? > I think so, because to me your confusion comes mainly from the v…

What are the problems you tend to encounter with purist REST APIs?

Re: Problems with RESTful APIs (2015)

#167

Post by naasking »

int_19h wrote: post #145
naasking wrote: post #64

Earlier quoted context omitted.

> And it's not always safe to retry POSTs. If POST is an insert, for example, retrying it would produce two inserts. [...] Suppose that you have sent a POST request, but before you could read the response, connection dropped. My previous post already covered idempotent POSTs via futures. The fact is, only the application can decide whether a POST is safe to retry arbitrarily or must be made safe by binding to a futur…

You assume the entire stack is HTTP end-to-end, which is not always the case.

How am I assuming that exactly?

Re: Problems with RESTful APIs (2015)

#168

Post by icebraining »

int_19h wrote: post #147
richardwhiuk wrote: post #76

Earlier quoted context omitted.

Why oh why oh why do you want a stateful read? That will be the beginning of the end for your architecture.

Because applications have state. In fact, the vast majority of reads in any applications are stateful (the database backing your app is also state, you know; I'm not talking just about session state here). By "pure" here I mean that we're talking about a pure function of its inputs.

Why do you need to distinguish between those? In fact, if the function is pure, why not run it on the client?

Re: Problems with RESTful APIs (2015)

#169

Post by naasking »

rantanplan wrote: post #154
naasking wrote: post #49

Earlier quoted context omitted.

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

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

How? Perhaps you should actually elaborate your argument. REST doesn't depend on the use of verbs, it's an architecture that elaborates the requirements for object designation (URLs), object lifetimes (statelessness) and hypermedia-driven service discovery (HATEOAS). Only GET and POST in HTTP are required to fulfill these requirements. If there's actually something wrong with that, then lay it out.

> 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

Except you can't in a world with side-effects. You could do exactly what you say if every POST were guaranteed to be idempotent. Every request could carry a full payload like a POST request and a unique identifier to ensure at-most-once semantics. That would be a fine protocol, and totally REST compatible. What's the problem exactly?

Finally, SOAP carries far more baggage than you imply. It's a false equivalency.

Re: Problems with RESTful APIs (2015)

#170

Post by discreteevent »

throwaway5752 wrote: post #74

What is it about CRUD over HTTP that drives some people nuts? A bit too much overhead, not perfect for high performance/low level data channels, and not perfectly standardized. But it piggybacks over a wildly popular level 7 protocol that takes care of security in a well tested way, already plays well with proxies/load balancers, has thousands of implementations in most languages, is well understood by network admins…

It's wildy successful for a reason, which is that its primary usee is by web browsers for document transfer. And as a result firewalls allow http over port 80 or https over 443. For a lot of cases you simply cannot communicate at all unless you use http. The reason for its success is that there is simply no other choice whether it's good or bad.
Post reply on HN