[coldtea]

REST was never that good to begin with.

(Not even as originally intended, which is very different from RESTful way 99% use it -- originally REST was all about self-reporting and discoverability, which is not used, and irrelevant to most use cases).

Having JSON as the response, and a scheme to address entities, was good. Even using HTTP action semantics was OK (though debatable). But that's far from what REST is about.

Something like JSON-RPC would be a much better for web API needs.

[atombender]

I'd argue that GraphQL is starting to fulfill the conceptual promise of REST: A universal, discoverable, self-describing API protocol. Every REST implementation ends up being ad hoc and not interoperable. With GraphQL you can point a documentation tool at a live server and get reference documentation for that API, for example. You get a schema, the ability to join collections of data together, parameterized queries, and more.

[iovrthoughtthis]

Are we just turning our application servers into database servers?

[rhacker]

Yes. When we write carefully crafted services that manipulate data based on a set of permissions and rules that make up what Twitter (for example) is, you're basically doing similar things that Postgres is doing when it writes data, it is looking at it's own set of permissions, etc..

So yes that's the exact analogy. We're writing databases on top of databases. Only ours are no-SQL.

[masklinn]

GraphQL decouples the API and the database entirely. You can implement graphql as a direct DB access, but it's certainly not the intent. Quite the opposite really, it was designed in not small part to provide the ability to aggregate and re-organise data from multiple sources in a single coherent API.

[marcosdumay]

You are missing the point.

GraphQL is a relational query language, just like SQL but only less powerful.

Fact is that people always wanted a just database anyway. But with some graphical interface on the front. Once we moved the interface to the client in an SPA, it seems unavoidable that backend will turn database-like.

[iovrthoughtthis]

Could we not just move the sql interpreter higher up the stack? Implement tables, views, functions as application code and use sql from the front end?

[FranOntanaya]

> originally REST was all about self-reporting and discoverability

I don't think this is accurate. Discoverability was the bonus score piece, the most fundamental parts were statelessness and caching.

A lot of grievances in early web development came from state breaking when people browsed back, reloaded pages, did other things between requests, or got hit by pretty aggressive caching.

Nothing intrinsically REST-blocking in the original zero JavaScript, form-based apps, they were just that messy and expected people to follow a linear path on a single browser window.

People where solving these problems for the first time (for the web), and they actually needed to be told to care for state.

[sureaboutthis]

That people misused REST is not what made REST "never that good" (in your opinion). In fact, it was this misuse that frustrated Dr. Fielding more than anything else.

[masklinn]

> That people misused REST is not what made REST "never that good" (in your opinion).

I used to be partial to that interpretation, but after a few years of looking at it, at what people do and at what's actually valuable, I've come to the conclusion that coldtea is correct: REST as originally intended was not that good for programmatic contexts.

It certainly didn't help that it got quickly buzzwordified as "actually use HTTP properly instead of just shoving your garbage through POST all the time" (the original sin of SOAP or XML-RPC), but even then what makes "REST" work for browsers (which is what the concept was extracted from) is that there is an intelligent agent doing the discovery and driving the interaction.

That's not useful for a programmatic API. You can add a discovery layer to a programmatic API (as e.g. graphql schemas & explorer tools) but requiring programmatic clients to go through such a discovery layer just makes interacting with the API painful for no value.

Traversing a few pages when clicking around in your browser makes sense, doing so from a programmatic client when you could literally just store the correct endpoint and perform your call directly is nonsense: it's inefficient, it's annoying and it's pointlessly verbose. Yet that is essentially what proper rest as described and clarified[0] by Fielding require.

Even the "multiple interpretations" (multiple content types) option is worthless when browsers don't provide the flexibility required to do content negotiation[1] or leverage HTTP verbs beyond GET and POST.

[0] https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

[1] even in places where they allow actual mimetypes it's as likely as not they'll ignore it e.g. object/@type is a mimetype but no browser I know cares about it, most of them send Accept: ∗/∗ and firefox sends its pagewise/default Accept.

[naasking]

> That's not useful for a programmatic API. You can add a discovery layer to a programmatic API

A discovery layer isn't necessary if you're using hypermedia as intended. "Discovery" just means a loosely coupled format associates the "logical" addresses, which your program shouldn't know a priori, with a readable name, which your program uses to find the logical addresses it actually needs.

It's like the difference between programming in assembly language with direct memory addresses (URLs), vs using a programming language that abstracts memory addresses with named variables (hypermedia format that associates readable names to URLs), thus decoupling clients from needing to understand potentially opaque URL formats.

The real problem with REST is that REST frameworks don't provide any guidance or support for any hypermedia format that isn't HTML, and HTML isn't well suited to programmatic interaction. None of the commonly used data interchange formats support distinguishing embedded links from other data, so they aren't hypermedia formats. No wonder doing REST right is so difficult.

> doing so from a programmatic client when you could literally just store the correct endpoint and perform your call directly is nonsense: it's inefficient, it's annoying and it's pointlessly verbose.

Except it's not pointless, it allows painless server-side upgrades. It might cost you some efficiency, but it provides significant flexibility.

[beders]

> Traversing a few pages when clicking around in your browser makes sense, doing so from a programmatic client when you could literally just store the correct endpoint and perform your call directly is nonsense:

That requires implicit knowledge of the 'correct' endpoint. If that endpoint changes or anything in between, you'll have to start versioning your API, which basically tells all existing clients: Sorry, you got to update.

Allowing clients to discover resources is a future-proof way to keep your client libraries compatible and evolve your API without versioning. It is more work for the client and it is not always suitable. But if you intend to design something future-proof (and we are talking about 10+ years), then REST has already proven to be very successful (your latest browser can still browse a web page from 15 years ago...)

[masklinn]

> That requires implicit knowledge of the 'correct' endpoint. If that endpoint changes or anything in between, you'll have to start versioning your API, which basically tells all existing clients: Sorry, you got to update.

In exactly the same way that the "RESTful" version requires implicit knowledge of the content types: that knowledge it not implicit at all, it is specifically and explicitly embedded in the system.

The word you're looking for is static.

> Allowing clients to discover resources is a future-proof way to keep your client libraries compatible and evolve your API without versioning.

That is completely untrue.

> But if you intend to design something future-proof (and we are talking about 10+ years), then REST has already proven to be very successful (your latest browser can still browse a web page from 15 years ago…)

Because it has a somewhat intelligent and flexible human driving it and able to adapt in changes to the visited targets. Not so with a programmatic client.

[dave_sid]

If users misuse a UI then the UI wasn’t designed well. If developers misuse REST then it’s their fault for not understanding REST.

[coldtea]

Exactly. And also: a UI could be badly designed even if its users don't misuse it.

Just because users might be extra careful in their use of a UI, doesn't mean the UI is not badly designed itself.

A big red button that says "Click me for free lemonade" but instead burns the whole computer is bad design -- even if the users have read the manual, so they know what it does and don't press it.

[coldtea]

>That people misused REST is not what made REST "never that good" (in your opinion).

You're absolutely correct.

It's not the misuse that made REST "never that good".

It was already not that good (again, in my opinion).