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

Most RESTful APIs aren't really RESTful

florian-kraemer.net

Post reply on HN
Print view View original

551–560 of 580 posts

Re: Most RESTful APIs aren't really RESTful

#551

Post by cyberax »

jerf wrote: post #538
cyberax wrote: post #418

Earlier quoted context omitted.

> There has been no lack of heavyweight, pre-declare everything, code-generating, highly structured, prescriptive standards Care to list them? REST mania started around early 2000-s, and at that time there was only CORBA available as a cross-language portable RPC. Microsoft had DCOM. And that was it. There was almost nothing else. It was so bad that ZeroC priced their ICE suite based on a PERCENTAGE OF GROSS SALES: h…

I don't just mean the ones that existed at the time of the start of REST. I mean all the ones that have come up since then as well and failed to displace it. Arguably the closest thing to a prescriptive winner is laying OpenAPI on top of REST APIs. Also, REST defined as "A vaguely HTTP-ish API that carries JSON" would have to be put later than that. Bear in mind that even after JSON was officially "defined" it's not…

> I mean all the ones that have come up since then as well and failed to displace it.

They won inside large companies: Coral in Amazon, Protobufs/gRPC in Google, Thrift in Facebook, etc. And they are slowly spreading outside of them.

OpenAPI is indeed an attempt to bring some order into the HTTP RPC world, and it's pretty successful. I'm pretty sure all the APIs that I used lately were based on OpenAPI descriptions.

So the trend is clear: move away from loosely-defined HTTP APIs into strict RPC frameworks with code generation because this is a superior approach. But once you start doing it, HTTP becomes a hindrance, so alternatives like gRPC are gaining popularity.

> Also, REST defined as "A vaguely HTTP-ish API that carries JSON" would have to be put later than that.

Ruby-on-Rails came out in 2005, and Apple shipped in 2006. REST-ful APIs were one of its major selling points ( https://web.archive.org/web/20061020014807/http://manuals.ru... ).

AWS S3 API, designed around the same time, also was fully REST-ful. This was explicitly one of its design goals, and it was not really appreciated by most people.

Re: Most RESTful APIs aren't really RESTful

#552

Post by bborud »

motorest wrote: post #483
cyberax wrote: post #360

Earlier quoted context omitted.

Just use gRPC or ConnectRPC (which is basically gRPC but over regular HTTP). It's simple and rigid. REST is just too "floppy", there are too many ways to do things. You can transfer data as a part of the path, as query parameters, as POST fields (in multiple encodings!), as multipart forms, as streaming data, etc.

> REST is just too "floppy", there are too many ways to do things. I think there is some degree of confusion in your reply. You're trying to compare a framework with an architecture style. It's like comparing, say, OData with rpc-over-HTTP.

In practical reality the distinction is mostly, if not completely, without a meaningful difference. The words "practical" and "meaningful" being key. The distinction only has relevance if one engages in pedantry. Or possibly some form of academic self-pleasuring.

I'm aware this is an unappealingly rustic reality, but it is nonetheless the reality experienced by most.

Besides in the practical world we are able to observe, REST isn't even an architectural style: it is several architectural styles multiplied by every possible permutation of how you address a dozen or more different concerns. Necessitating disambiguation whenever you talk about it. First to state the obvious, that it isn't really what Fielding described, then on to communicating what vector describes your particular permutation of choices.

It's okay. We don't need to pretend any of us care about REST beyond as an interesting academic exercise.

Re: Most RESTful APIs aren't really RESTful

#553

Post by bborud »

PaulHoule wrote: post #371
cyberax wrote: post #360

Earlier quoted context omitted.

Just use gRPC or ConnectRPC (which is basically gRPC but over regular HTTP). It's simple and rigid. REST is just too "floppy", there are too many ways to do things. You can transfer data as a part of the path, as query parameters, as POST fields (in multiple encodings!), as multipart forms, as streaming data, etc.

People get stuff done despite at all that.

People got things done with flint axes too. It isn't really a useful argument.

Re: Most RESTful APIs aren't really RESTful

#554

Post by bborud »

cyberax wrote: post #546
motorest wrote: post #514

Earlier quoted context omitted.

> This is a recent project. OData officially started out in 2007. Roy Fielding's thesis was published in 2000.

So it was a contemporary of Protobufs, Cap’n Proto, and other frameworks. Facebook had Thrift, Amazon had Coral, and so on. They appeared almost simultaneously, for the very same reason: REST by itself is too vague and unreliable.

I think all of them came a bit later. And I do remember Thrift. With regret.

Re: Most RESTful APIs aren't really RESTful

#555

Post by troupo »

lalaithion wrote: post #291
troupo wrote: post #257

Earlier quoted context omitted.

> From my point of view, post, put, delete, update, and patch all do the same. That's how we got POST-only GraphQL. In HTTP (and hence REST) these verbs have well-defined behaviour , including the very important things like idempotence and caching: https://github.com/for-GET/know-your-http-well/blob/master/m...

Yeah but GET doesn’t allow requests to have bodies (yeah, I know, technically you can but it’s not very useful), and this is a legitimate issue preventing its use in complex APIs.

I've had situations when I wanted a GET with a body :) But not that many

Re: Most RESTful APIs aren't really RESTful

#556

Post by Jenk »

motorest wrote: post #527
Jenk wrote: post #519

Earlier quoted context omitted.

The below type definition (TS) fits the ECMA schema for JSON: type JSON = string | number | boolean | null | JSON[] | {[name: string]: JSON}

You didn't answered my question.

I'm not the person you asked.

Re: Most RESTful APIs aren't really RESTful

#557

Post by brigandish »

paulddraper wrote: post #544
brigandish wrote: post #506

Earlier quoted context omitted.

It was limited up until the last 10 years, and if someone hasn't updated their knowledge then it's still limited, I suppose.

XMLHttpRequest? fetch? We're talking JSON APIs -- HTML forms are incompatible with that no matter the verb.

Fetch came in around 2015, and XMLHttpRequest wasn't consistent in the way different verbs were handled, like redirects, as this blog post[0] from 2006 points out:

> Basic redirect support is pretty universal, but things quickly fall apart on most browsers when you do tricky things like use non-GET/POST methods on redirecting resources.

There were other things too, I'm not sure CORS supported anything but GET and POST early on either. Wanting consistency and then sticking to it isn't an inherently bad thing, there's a lot to know, and people don't update knowledge about everything (I'm speaking generally as well as including my self here).

[0] https://www.mnot.net/blog/2006/01/23/test_xmlhttprequest

Re: Most RESTful APIs aren't really RESTful

#558

Post by PaulHoule »

bunderbunder wrote: post #539
agumonkey wrote: post #386

Earlier quoted context omitted.

When I realized that I was calling openapi-generator to create client side call stubs on non-small service oriented project, I started missing J2EE EJB. And it takes a lot to miss EJB. I'd like to ask seasoned devs and engineers here. Is it the normal industry-wide blind spot where people still crave for and are happy creating 12 different description of the same things across remote, client, unit tests, e2e tests, o…

I keep pining for a stripped-down gRPC. I like the *.proto file format, and at least in principle I like the idea of using code-generation that follows a well-defined spec to build the client library. And I like making the API responsible for defining its own error codes instead of trying to reuse and overload the transport protocol's error codes and semantics. And I like eliminating the guesswork and analysis paraly…

I can write frickin' bash scripts that handle JSON APIs with curl, jq, here quotes and all that.

A lot of people just do whatever comes to mind first and don't think about it so they don't get stuck with analysis paralysis.

   curl -fail
Handling failure might be the real hardest programming problem ahead of naming and caches and such. It boggles my mind the hate people have for Exceptions which at least make you "try" quite literally if you don't want the system to barrel past failures, some seem nostalgic for errno and others will fight mightily with Either or Optional or other monads and wind up just barreling past failures in the end anyway. A 500 is a 500.

Re: Most RESTful APIs aren't really RESTful

#559

Post by PaulHoule »

actionfromafar wrote: post #531
agumonkey wrote: post #530

Earlier quoted context omitted.

The pattern I observe is that in old industries, people who paid the cost, try to come up with a big heavy solution (xml, xsd, xpath), but newcomers will not understand the need, and bail onto simpler ideas (json), until they hit the wall and start to invent their own (jsonschema, jquery). same goes for java vs php/python

Definitely. And often, it's the right call, or the thing wouldn't generate any business value (such as money) at all in a reasonable time. But boy, how messy spaghetti don't we get for it, sometimes. (Invent their own, badly , at first. Sigh.)

I dunno, I remember the holy trinity of $, % and @ sigils in Perl as my first exposure to JSON-like objects which are the real world's answer to S-Expressions because they address the nameless tuple problem

https://www.codeproject.com/Articles/1186940/Lisps-Mysteriou...

Re: Most RESTful APIs aren't really RESTful

#560

Post by PaulHoule »

tbrownaw wrote: post #454
yndoendo wrote: post #333

Earlier quoted context omitted.

Always thought that a standard like ISO8601 which always stores the date and time in UTC but appends the local time zone would beneficial.

Sometimes you need your timestamps to be in a named timezone. If I have a meeting at 9am local time next month, I probably want it to still be at 9am even if the government suddenly decided to cancel daylight time.

There are a few things you want about dates. 1932-04-12 sorts lexically, 04/12/1932 doesn't. So long as you don't use a timezone or always use the same timezone (especially Z) you get this nice property with ISO 8601 which makes it better than the alternatives. Once you include timezones you get into all sorts of problems such as dates (as opposed to date times) only having a partial ordering as the day here in New York starts an hour earlier than Chicago. In an extreme case the Pearl Harbor attack was launched the day after it was executed.

At some point you need real time aware libraries and whatever language you use they've been through several iterations of them (Javascript Date, moment, dayjs, ...) because they got it wrong the first time and probably the second time to.

With ISO 8601 it is easy to get the yyyy, yyyy-mm, hh and other things you might work with primitive tools (awk). Getting the day of the week or the time involved is not hard which gets you to the chronological rosetta stone

https://en.wikipedia.org/wiki/Julian_day

which is a multiplier and and offset away from Unixtime except for all those leap seconds and whatnot. With Unix timestamps comparison is easy and differences are easy and even knowing it is Thorsday is easy; they don't sort as strings but GNU sort has a -n option, only trouble is it is a bunch of twisty little numbers that look alike.

Post reply on HN