Earlier quoted context omitted.
Brilliant!
I know you're not supposed to complain about downvotes, but seriously?! A complement about a witty comment gets me downvoted. I give up.
That's what the upvote button is for.
How did REST come to mean the opposite of REST?
311–320 of 393 posts
Re: How did REST come to mean the opposite of REST?
#312Earlier quoted context omitted.
As someone who has implemented S3 (TL for Cloudflare R2) I’ll choose to disagree that the RESTfulness of the S3 API is a resounding success. Just go ahead and try to write the code to route requests. So many features are likely excluded just because Amazon couldn’t figure out how to jam it into HTTP verbiage. So sure. S3 is implemented on top of REST but I’d much rather pick a proper RPC protocol. The only reason to…
Does R2 also exposes an R2 specific interface or does it only offer the S3 compatible interface?
It supports APIv4 (JSON REST API consistent with how all other Cloudflare APIs are managed) and Worker bindings (JavaScript API). The former is how the UI is implemented (not currently documented beyond creating and deleting a bucket because we haven’t taken time to review/stabilize the API for proper REST semantics). The latter doesn’t use REST but instead has a hacked up JSONRPC-like mechanism (which we’ll rip out at some point once the runtime makes certain things easier).
Re: How did REST come to mean the opposite of REST?
#313”REST must be the most broadly misused technical term in computer programming history."
I think OOP and REST are neck-and-neck on this one.
Re: How did REST come to mean the opposite of REST?
#314Earlier quoted context omitted.
JSON is syntactically valid JavaScript, why do you say it's not compatible with JavaScript?
Not all JSON is syntactically valid javascript.
Since ES2019[1], all JSON is valid JavaScript with U+2028 and U+2029 being accepted as unescaped characters in strings.
Re: How did REST come to mean the opposite of REST?
#315Because no one knows what the hell the acronym means, except that it sounds good. Everyone wants to be RESTful. RESTful is chill. It's resting - good programmers are lazy! But RESTful is resting while using an acronym , which is technical and sophisticated. To be RESTful is to be one of the smart lazy ones. Now if you're one of the few who cares what your acronyms mean, you look it up and ... "representational state…
This is hilariously inaccurate. There’s a whole dissertation on what REST is and it’s easily graspable, if you care to read it. REST is about hypermedia, if there is not hypermedia, it is not REST. It must be said that confidence with which you present your inaccurate assertions is only going to make others as confused as you are.
If you found it hilarious, well, that was the point: the words in the acronym are very un-denotative, so it encourages deconstruction to mean whatever the reader wants it to mean.
If I truly want people to understand what I'm talking about, rather than just make something popular, I don't give them evocative, fluffy slogans and then direct them to a dissertation to find out what the fluff really means. I use carefully chosen, denotative words in my slogan.
HATEOAS is a good example of prizing clarity over vague evocativeness. It's all about hypermedia, so hypermedia is in the acronym.
If I don't do this, I can't be too upset at what predictably ensues, as people take my cool-sounding slogans and repurpose them to legitimize their own ideas.
Re: How did REST come to mean the opposite of REST?
#316Earlier quoted context omitted.
I disagree about well-developed error codes. Examples: * There is no useful distinction between different kindes of bad requests (syntactically wrong, structurally wrong, not applicable to the data found, etc.) * Special handling is needed to test if a resource exists -- you cannot just GET it and check for a 404 code because browsers log all 404 as errors, even if it's the "happy path" * The error codes confuse auth…
The way I think of the status codes is as instructions for how a generic HTTP client or proxy should or may behave in response. Any status code which, in practice, does not affect generic client behavior, does not need to be distinguished in the status code (and can instead be distinguished in the body of the response). For example, status 412 can be thought of as "try the transaction over again, your information abo…
> You could go all WebDAV with status 422 for non-syntactic errors, but I am skeptical of its utility.
FastAPI uses 422 for "your data is structured wrong for this schema" and it's better than sliced bread.
I think the worst part about the 4xx/5xx distinction is that it doesn't really tell you whether the request is failing in a transient or permanent way (or can't tell). It would have been nice to have more leading digits (6xx, 7xx) and make some distinctions:
- the client did something wrong but might be able to succeed later if state changes (403, 404, 429)
- the client did something wrong and the result is unlikely to change without changing the request (405, 422)
Same with the 5xxs, split into "server" (endpoint) failed, vs middleware (load balancers, etc) failed or is overloaded.
Re: How did REST come to mean the opposite of REST?
#317Earlier quoted context omitted.
That feels like a pretty significant quibble. API stands for “application programming interface”. If you cannot write an application to programmatically interface with it, why would you call it an API? What you and the parent see REST as, should be called an HPAI: “human-poking-around interface”.
You can see the HTML website as a API, just because it’s hard and annoying to interface with it from another application doesn’t mean that you can’t.
Right. But the issue wasn’t whether you can interface with one via other applications, but whether you can do so while adhering to the REST principles Fielding gave, which require that you not have any context to interpret a response other than the response itself. So no out-of-band communication like documentation or your previous use or the site.
At that point, you do need a human at each point, and you can’t program against it. Programmatically interacting involves precisely the things REST principles prohibit, hence this point in the discussion.
Re: How did REST come to mean the opposite of REST?
#318Excellent explanation. But I think plenty of technology has been misunderstood as of late. I've been in this industry two decades, but it's only in the past 5 years that I've noticed entire teams of absolute morons entering the field and being given six figure jobs without understanding what their job even is, much less how to do it properly. (And by "properly" I mean "know what a REST API is") The industry is awash…
This has always been the case, you just weren't experienced enough to realize it
Re: How did REST come to mean the opposite of REST?
#319Earlier quoted context omitted.
> no sane client will go around and request random server-provided urls to discover what is available. "Random" isn't what's supposed to happen. You hit a top level endpoint, and then at that point other endpoints are made manifest, and then the UA/client and the user decide together what the next relevant endpoint is. And this is what happens all the time with the most common client (the browser). Seems to have work…
> You hit a top level endpoint, and then at that point other endpoints are made manifest, and then the UA/client and the user decide together what the next relevant endpoint is. That's not how APIs are used. APIs consume and provide data. Raw data is unsuitable to be presented to the user. That's why HTML has so many formatting options. Formatting information is completely missing from APIs. > Seems to have worked mo…
> XML/markup does not map well to basic data types in current programming languages. These work with strings, ints, floats and arrays/dictionaries thereof. Not Nodes, Elements and attributes of unknown/variant data types
Exactly.
Arrays are pretty much the most primitive computer data structure (aside from primitives), and the contortions XML must go through to express them is remarkable. So much ceremony, and it can't do a simple list. XML has this core implicit assumption that everything ought to be an object, and I think this was the ultimate death knell for it. You can add complexity to JSON (e.g. JSON-LD) but you can't take the complexity out of XML.
Re: How did REST come to mean the opposite of REST?
#320The short answer is... the web moved in a different way than expected and the useful portions of rest were preserved while other portions were jettisoned (the biggest one IMO isn't the hypertext portion (JSONs fine, it's fine ) but the self-discoverable portion - I haven't seen a self-discoverable REST API ever in the wild). Unfortunately the name REST was too awesome sounding and short - so we've never had a fork wi…
> a self-discoverable REST API I’ve been writing web services for over a decade and this just seems like a cute idea that is actually almost never at all useful in the real world.
Swagger/OpenApi is probably the closest thing to "true REST" with self-discoverable APIs. Without some sort of common schema of where/how to look for resources, there's no real automated discovery to be had without AGI.
Turns out, a lot of places don't even want self-discovery. We shut off our openapi.json in prod because a) security b) we don't want bots messing around c) Hyrum's law, as soon as you expose an API endpoint, folks try to build against it and grumble if it chances/goes away.
Wikipedia (along with any true wiki) is, and likely forever will be, the one true REST/HATEOAS application.