Most things on the web are half-assed, and half-assed HTTP APIs enable rapid results (before the problems start).

REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design.

It didn't help that REST began to trend as an idea right around the same time that intentionally schemaless JSON was replacing schema'd XML documents as the preferred way of over-web information interchange. For consumers, schemaless JSON snippets were attractive for partial processing; for developers, they were attractive for rapid iteration. For makers of "Web 2.0 Mashups", JSON-returning APIs were attractive because processing XML with circa-2006 "cross-browser" nightmare-mode Javascript was about as pleasurable as pulling teeth.

People saw these APIs being called REST, they tried to understand REST, got overwhelmed halfway through, called it REST-like or RESTful instead, and that's how we arrived at where we are.

During this time, RPC wasn't cool or buzzword-compliant, so the people who still RPC did it for good reasons and didn't really blog about it. The quip to consider RPC is nonetheless valid; stuff like gRPC or Thrift are at least proper RPC frameworks, and a much better idea than someone trying to ducktape something with GET and POST for the millionth time.

Luckily, soon, GraphQL will be the newest entrant in this space, and will have to contend an influx of superficially-informed people enticed by its promise. It may have a better track record than REST, because a partial implementation of GraphQL will better resemble GraphQL than a partial implementation of REST will resemble REST.

It helps that GraphQL has an actual spec, protocol, and defined schema and is intended to be shipped as a separate microservice that just implements your schema according to the spec.

REST is more "hodge podge of concepts" that you can hack on and pollute and misunderstand at will.

I guess nothing will stop people from making Frankenstein schemas or poorly performing resolvers but at least the consumption is mostly uniform?

Some people would rather take a hodge lodge of concepts over a hodge podge of implementations. HTTP clients have been done to death, GraphQL clients on the other hand...

>REST is not fundamentally inappropriate, it just needs a lot of careful design about domain objects, link relations, and media types. Generally, people are not very good at thoughtful design.

Especially if it's not worth the effort.

Generally, people are not very good at determining if thoughtful design is worth the effort.

Yes, waterfall was a mistake, but design-nothing is mistaken too. Thinking before doing helps avoid waste & rework.

Honestly, this should be a common part of web frameworks by now. It's a travesty that our industry hasn't developed a solid foundation for this kind of thing 16 years after it was published.

The best we've got on this mark is the Waterken server, which is pretty good, but not good enough.

"Most things on the web are half-assed,"

That's my impression too.

> Have we considered that these REST "anti-patterns" exist because REST is fundamentally inappropriate for what most people are trying to use it for?

Or perhaps people actually don't understand REST, but think they do, thus leading to endless blog articles about "REST levels" and other nonsense.

> What if you can't shoehorn your functionality into the handful of REST verbs?

GET and POST can represent any arbitrary program (they map to the lambda calculus after all). You don't need any more than that, in principle. The other verbs are merely optimizations.

> What ever happened to plain old RPC?

The inescapable failure modes of RPC are exactly what REST addresses.

There's nothing really wrong with RPC in my book, just don't call it REST when it's not. I'd say the bigger issue is that a large number of people implement an RPC variant and call it REST because it's on HTTP and not SOAPy.

Is RPC just ad hoc endpoints? The info on REST is overwhelming, to many different opinions, for a simple SPA do programmers really need a formalized client-server contract? Can one just access server capabilities through ad hoc endpoints and write custom code to fetch the data they need? servers define procedures, and they return data.

I ask because I'm going to start writing my first http api for a small SPA.

It just causes so much busy work. Then busy work leads to bugs, which leads to framework abstractions, which leads to implicit nuance in almost every part of web development.

RPC and client-server contracts, as well as static-typing, is a bloody god send and the whole world will be in a better place once we formalize and accept it (I didn't say standardize I said formalize).

I'll defend REST's utility for simple data retrieval. If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice.

More complex use cases, and specifically non-idempotent operations, is where I find REST doesn't hold up as well as RPC.

> If I just need a paginated list of comments on a video, being able to quickly hit /video/1093/comments and get that list back is really nice.

REST isn't about human-readable URLs. The link to the comments should have been part of the representation returned for /video/1093 (typically JSON these days, so a "comments" property of the object).

As ben_jones stated, a client and server need a formalized contract or you're doomed to break things. Whatever you use needs to at a minimum be: - internally consistent - sufficiently documented that a developer on either side understands what the other side does

REST is just a set of rules to follow that attempt to avoid some pitfalls and provide a common parlance.

nothing wrong with a good well documented json rpc over http

the main difference is endpoint negotiation vs object state transfer - consider an account representation - if you can withdraw, the link to perform the withdraw operation is there in the server response. if you can't, the link to the withdraw operation is not there. this is how the returned value convey the object state and how it let client explore object operarions.

say, it's the difference between returning an object instead of a struct, and it's also why json alone is not compatible with rest, there's not an agreed schema to identify operations coming along with the data so that a client can actionit - json-ld and hal can, if you reallyhate the idea of xml tho.

Don't write an API. Use something like reindex.io.

As a shorthand, think of REST as about nouns, and RPC about verbs.

/account/1 is REST because the you're looking for an account (noun), the account id is 1, and you're using the HTTP method GET.

/search/hello is RPC because it uses a specific verb (search) to call a remote procedure to search for the 'hello' keyword. You're taking an action for which there is no appropriate HTTP method, so RPC can be used instead of REST.

This doesn't cover 100% of every situation, but it's useful as a quick mnemonic.

That's incorrect. REST has no such restrictions on URLs. URLs can be completely random numbers with no human-discernible meaning.

REST is about architecture, about where state should live, how long it should live, how messages between entities should designate resources/state, all so you can preserve encapsulation and maximal flexibility for service upgrade. Your service is not RESTful if you don't meet these criteria.

RPC has no such restrictions, which means you're free to do everything wrong, which virtually everyone does, and you'll still be doing RPC correctly.

> /account/1 is REST

Probably not. If "what this is and how it relates to other things" is determined by looking at the URL path and not the media type (for "what it is") and link relationshops (for how it relates to other things) it's not REST.

And that's the issue. Most engineers don't understand HTTP. Just the amount of people who confuse PUT and POST is pretty high. Getting people to remember that media type exists is hard. Add in the rest, it's just not happening.

But the unicorn "properly designed REST api" is quite nice.

Since i can't trust anyone to do it right though, I'll just use GraphQL because its easier to get people to do right.

Reading over your comments, I'm curious what you would consider to be an API that properly implements REST principles according to the original dissertation.

When people mention RPC in this context, are they talking about a generic concept, or are they referring specifically to SOAP? Because SOAP was always a complex mess, pretending that WSDL files somehow added semantic meaning to data, when it fact it was just a serialization format with excessively verbose data typing and validation of element presence/counts. SOAP made even the smallest projects feel like a bloated nightmare typical of "Enterprise bureaucracy". SOAP is the very reason why people eagerly latched onto JSON and REST the moment it became viable.

For a public facing interface, I haven't really found REST to be lacking. Adherence to REST buys you simplicity and (if kept to the standards) some implicit understandability.

That said, REST is not the right fit for _every_ use case. The same simplicity mentioned as a strength also limits its flexibility. I think this is no more abundantly clear than microservice oriented architectures. More and more these architectures are moving towards different patterns/protocols for various reasons (gRPC comes to mind).

> What if you can't shoehorn your functionality into the handful of REST verbs?

REST doesn't have a handful of verbs, HTTP has a handful of predefined verbs (but supports extensions). REST is an architectural style that does not specify the underlying protocol.

> What if none of the status codes make sense?

Again, that's an HTTP issue not a REST issue. And it's not likely to be a real issue (HTTP status codes may be insufficiently precise—but already support additional data for disambiguation—but I can't imagine a situation where none of them make sense.)

Much as I would like to agree with you, that war was already fought and lost in the early '00s. Port 80/443 were the two ports that couldn't ever be firewalled because web browsing depended on them, so everybody rushed to cram their RPC requests into some kind of HTTP-based protocol.

HTTP != REST though, as the article notes. There are other ways to use port 80/443 that neither violate HTTP nor go full REST - websocket being an (extreme) example.

Even the HTTP monopoly is changing. There are lots of new protocols (HTTP2, QUIC, WebRTC) that work besides firewalls and things like ALPN gives a standardized way to tunnel new protocols over an encrypted connection.

>HTTP != REST though, as the article notes.

The article might note it, and Roy might insist on it, but nobody cares.

For all intents and purposes, what people call REST in practical use is RPC over HTTP with JSON responses.

But then these people are just very wrong. No point encouraging them either :)

The entire industry is just people who are very wrong hitting critical mass until no one remembers what was right.

> HTTP != REST though, as the article notes.

Well, HTTP itself is the archetypical REST API, though.

> What ever happened to plain old RPC?

IDK. Whatever happened to plain old REST HTTP?

Totally agree. REST is a good idea for some use cases but now people want to force it into everything.

But this seems to be the case for a lot web stuff.

Maybe it's time to add an EXEC action? Where the input arguments are either query-string and/or body parameters...

Most use POST for that now, but there is room, or should be room for RPC-style endpoints in a mostly REST service, and vice-versa.

A combination of REST and Web Sockets works pretty well.