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

211–220 of 224 posts

Re: Problems with RESTful APIs (2015)

#211

Post by Avernar »

codr4life wrote: post #27
coldtea wrote: post #21

Earlier quoted context omitted.

> I'm going to have to call bullshit on that one. And yet you don't provide a single concrete reason. And even go on to say the non-REST way you use REST at your team. > REST is one of the more successful strategies we've come up with for connecting systems, this is just another case of letting perfect stand in the way of good enough. Using GET for non-destructive operations and POST for updates and deletes is a nice…

You might do well to read what I wrote about perfect and good enough. These are ideas, not laws.

Taking ideas from REST and putting it into your JSON-RPC API doesn't make your API REST. But you call it REST anyways.

It's like reading a book on building a house and using ideas to build a shed. Sure your shed has electricity and a sink but it's still a shed, not a house.

Same with terms like RESTful. You don't call your shed a "house like building" as it's missing key pieces of a house.

REST requires HATEOAS. The only real implementation is the world wide web. Everything else is really JSON-RPC or some other protocol with a few ideas borrowed from REST.

Re: Problems with RESTful APIs (2015)

#212

Post by paulddraper »

eranation wrote: post #192
paulddraper wrote: post #87

Earlier quoted context omitted.

JSON, as the name suggests, is easily and natively consumable by JavaScript, the only language to run natively in web browsers. And everyone uses a web browser. Ergo, if you develop an HTTP API, you should do it with JSON so it can work easily in web browsers.

Can you elaborate please? Browsers had native XMLHttp support before they had JSON support. The fact JSON (use to be) a subset of JavaScript and the browser runs JavaScript natively is not convincing. Other than evil eval(jsonString) (before JSON.parse was available) which is basically asking for XSS, what benefit you get from JSON being consumable by JavaScript? I think XMLHttp was available in browsers (in a vendor…

The XML in XMLHttpRequest is meaningless.

eval() was present from day 1 and is the reason JSON looks like it does. Obviously it requires complete trust in the source (historically, the same origin).

Re: Problems with RESTful APIs (2015)

#214

Post by naasking »

int_19h wrote: post #206
naasking wrote: post #171

Earlier quoted context omitted.

Requesting an insert can be idempotent. Each non-idempotent operation is tagged with a unique identifier, if the server doesn't have inserted data tagged under that identifier, then it performs the insert, if it does, then it returns the usual success code as if it had just performed the insert. This unique identifier is simply a durable representation of a future which I described above.

This would seem to require the identifiers to be attached to records in perpetuity (i.e. it would basically require client-generated IDs everywhere), so that the server can reliably verify that this operation has already produced a record. I can see it working, but it's a far-reaching change, that may not be easy to adopt for existing data storage schemas.

> This would seem to require the identifiers to be attached to records in perpetuity (i.e. it would basically require client-generated IDs everywhere)

Not sure what you mean by client-generated. The server-side app generates the id because it has to store and interpret it. This can be as simple as a sequence number, similar to how TCP guarantees delivery. It depends on the schema really.

This is the simplest way to ensure you can perform arbitrary retries of POST in case of a network partition.

This data doesn't even need to be integrated with your app's schema, although that's ideal so you can manage the storage lifetime. But you could use an entirely separate store for GUIDs and cached replies, and so it becomes transparent to your app and just becomes another layer.

Re: Problems with RESTful APIs (2015)

#215

Post by edejong »

user15672 wrote: post #194
edejong wrote: post #95

Earlier quoted context omitted.

Really? I made one yesterday based on a WSDL from a customer. The whole API was auto generated in type safe Scala in seconds. After adding authentication configuration and some sensible timeouts, I had the whole thing running in two hours. The SOAPui auto generated a mock test and load tests with which I could mimic specific weird responses. The REST API I had to forward through however had no good documentation, no…

Did you really just complain that REST is bad because you couldn't find an auto-generation tool to do your work for you? Because that's hilarious. Also, you don't seem to have looked terribly hard, because there are a few really powerful tools out there for autogenerating server and client code for REST APIs, as well as mock servers and a whole host of other tooling (See: Swagger, RAML, API Blueprint for starting poi…

I wonder how you arrive at your conclusions. It's rather hilarious, to be honest. I've found that good machine readable specifications of rest interfaces are as rare as well designed SOAP interfaces.

I've used a variety of tools to generate and test REST interfaces in the last ten years. To a mixed success, I must say.

Re: Problems with RESTful APIs (2015)

#216

Post by int_19h »

naasking wrote: post #213
int_19h wrote: post #205

Earlier quoted context omitted.

"The PUT is merely a small optimization that is now obviated by the spread of HTTPS."

Still not seeing how that line means I'm assuming HTTP end to end.

If I understand your point correctly, you're saying that when something is talking over HTTPS, the middleware doesn't get to see the verbs, and so it can't optimize for them anyway. But if part of your connection is using different transports, then middleware in those segments can observe the verbs and react accordingly (including e.g. local retries in face of adverse network conditions, to avoid expensive end-to-end roundtrips).

Re: Problems with RESTful APIs (2015)

#217

Post by int_19h »

naasking wrote: post #214
int_19h wrote: post #206

Earlier quoted context omitted.

This would seem to require the identifiers to be attached to records in perpetuity (i.e. it would basically require client-generated IDs everywhere), so that the server can reliably verify that this operation has already produced a record. I can see it working, but it's a far-reaching change, that may not be easy to adopt for existing data storage schemas.

> This would seem to require the identifiers to be attached to records in perpetuity (i.e. it would basically require client-generated IDs everywhere) Not sure what you mean by client-generated. The server-side app generates the id because it has to store and interpret it. This can be as simple as a sequence number, similar to how TCP guarantees delivery. It depends on the schema really. This is the simplest way to e…

> Not sure what you mean by client-generated. The server-side app generates the id because it has to store and interpret it.

Per the description above:

"Each non-idempotent operation is tagged with a unique identifier"

Since the operation originates on the client, the client has to tag it with the identifier, no? And the server has to store this identifier in a way that associates it with any data affected by that operation in a non-idempotent way.

Or are you saying that the client first has to make a round-trip to the server to generate the ID, and then use that server-provided ID for the actual POST?

Re: Problems with RESTful APIs (2015)

#218

Post by naasking »

int_19h wrote: post #217
naasking wrote: post #214

Earlier quoted context omitted.

> This would seem to require the identifiers to be attached to records in perpetuity (i.e. it would basically require client-generated IDs everywhere) Not sure what you mean by client-generated. The server-side app generates the id because it has to store and interpret it. This can be as simple as a sequence number, similar to how TCP guarantees delivery. It depends on the schema really. This is the simplest way to e…

> Not sure what you mean by client-generated. The server-side app generates the id because it has to store and interpret it. Per the description above: "Each non-idempotent operation is tagged with a unique identifier" Since the operation originates on the client, the client has to tag it with the identifier, no? And the server has to store this identifier in a way that associates it with any data affected by that op…

> Or are you saying that the client first has to make a round-trip to the server to generate the ID, and then use that server-provided ID for the actual POST?

This is always the case for REST given HATEOAS, ie. you've already made some hypermedia requests to obtain the URL of the endpoint to which you will POST.

Unless the resource you're posting to actually is the public entry point of your service, but that would be very unusual.

Re: Problems with RESTful APIs (2015)

#219

Post by naasking »

int_19h wrote: post #216
naasking wrote: post #213

Earlier quoted context omitted.

Still not seeing how that line means I'm assuming HTTP end to end.

If I understand your point correctly, you're saying that when something is talking over HTTPS, the middleware doesn't get to see the verbs, and so it can't optimize for them anyway. But if part of your connection is using different transports, then middleware in those segments can observe the verbs and react accordingly (including e.g. local retries in face of adverse network conditions, to avoid expensive end-to-end…

While technically correct, I'm not sure how this is useful. You use HTTPS to communicate with an endpoint you trust, and anything beyond that is internal network infrastructure which is much more reliable than the HTTPS hops. The utility of local retries on this last hop don't seem compelling.

Re: Problems with RESTful APIs (2015)

#220

Post by dragonwriter »

naasking wrote: post #64
int_19h wrote: post #59

Earlier quoted context omitted.

The point of having something like PUT (that is known to be imdepotent) is that it can be retried by any of the layers in the stack, instead of having a full roundtrip back to the client on every retry. And it's not always safe to retry POSTs. If POST is an insert, for example, retrying it would produce two inserts. And this can have interesting consequences when processing responses. Suppose that you have sent a POS…

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

> The PUT is merely a small optimization that is now obviated by the spread of HTTPS.

Idempotence can be useful knowledge for client-side caches, so HTTPS doesn't obviate the value of the PUT (or, for the same reason, DELETE) vs. POST distinction.

Post reply on HN