I agree with you. For most people, switching to REST is useless, because they're still attached to the conceptual framework of RPC. We're still in the dark ages, re-writing the wheel again and again and again, coding clients for each single service out there. It's not wonder that REST seems useless.
But there's a vast network of services, far bigger than all the RPC APIs out there, that isn't like that. Where clients can connect to different services - even services made years after them, with functionality they couldn't have anticipated - without having to be tailored to them. Where the user can switch the provider of a specific service without having to switch clients, because the protocols are standard and compatible.
I'm talking, of course, about the HTML Web. Where people implement RESTful services without even knowing what they are, just because following a standard is just painfully obvious.
REST is the way we can implement something better; instead of dumb clients, we can have smart agents that interact with the rest of the web as browsers now do, but without the user hand-holding it. And gradually switching RPC to REST is the only way to accomplish that.
REST is one of the stupidest ideas to have ever come out of HTML.
When you write a class do you only have 4 methods on it? Create, Read, Update, Delete?
Case shut & closed.
But, but, but, I hear you say? It's not about the verbs, it's about the intention behind the verb?
Any GET you do to the system inherently changes it. I log you accessed the system, it often changes the way the object behaves (for example, you viewed it, it is now more popular, it now appears higher in results).
I could go on for hours about how virtually every concept in REST is obviously flawed if you are an experienced programmer and simply sit down and think about it.
It doesn't work!
So the concept was flawed from the beginning.
RESTful APIs died a long time ago, but somehow some people are hanging on to the archaic meaning of REST without really realizing that 'REST' now simply means 'API over HTTP'. The best APIs simply dropped supporting RESTful interfaces a long time ago and those crazy people who stick to it, like Google, have to contort their APIs into utter messes just to facilitate it.
Worse, people are still building entire systems based off its flawed nature. Microsoft just released WebAPI which tries to force you into a RESTful model. But then again, they never really have understood the web.
When you write a class do you only have 4 methods on it? Create, Read, Update, Delete?
Just because you are unable to stop thinking in terms of classes, doesn't mean REST is flawed. REST doesn't have classes, it has resources, and they work differently.
Any GET you do to the system inherently changes it. I log you accessed the system, it often changes the way the object behaves (for example, you viewed it, it is now more popular, it now appears higher in results).
GET is not part of REST, it's part of HTTP, which is a particular implementation of a RESTful architecture. The flaws of HTTP are irrelevant to whether REST makes sense or not.
It doesn't work!
Your line is self-disproving, since you used a RESTful service to send it. The web has literally billions of services following REST. The proof that it works is shown again every time you click a link.
RESTful APIs died a long time ago, but somehow some people are hanging on to the archaic meaning of REST without really realizing that 'REST' now simply means 'API over HTTP'. The best APIs simply dropped supporting RESTful interfaces a long time ago and those crazy people who stick to it, like Google, have to contort their APIs into utter messes just to facilitate it.
Again, you've used a RESTful API to post this very message. RESTful APIs work, it's RPC with a RESTful facade which doesn't, and it can't die soon enough.
There is however one use case for which I haven't found a good way to use REST: have the client upload a document to the server and return the same document in a single call, transformed (say, applying an XSL server-side). You're not really creating a new resource here, or accessing an existing one.
But I agree that in most cases, REST is good enough, and certainly a hell of a lot better than old-style RPC or "let's-put-an-action-verb-in-the-URL-and-call-it-REST" HTTP APIs.
What happens if the connection is lost during the conversion? Do you really want to force the client to send it again and redo the conversion? Is the document time sensitive enough that it's better to repeat the process?
If not, then I'd say that it does make sense to create a new resource: the document. You create it by POSTing the original, and the server returns a 201 Created, with a Location header pointing to its new URL. The client can then GET it to download the converted version. The document resource should have a TTL so that it can be pruned from cache.
I don't think REST fits all use cases, and RPC does make sense when your needs don't fit the advantages of following REST, but I don't think that's the case here.
> What happens if the connection is lost during the conversion? Do you really want to force the client to send it again and redo the conversion? Is the document time sensitive enough that it's better to repeat the process?
No, I don't think it would be an issue to repeat the process in this case.
> f not, then I'd say that it does make sense to create a new resource: the document. You create it by POSTing the original, and the server returns a 201 Created, with a Location header pointing to its new URL. The client can then GET it to download the converted version. The document resource should have a TTL so that it can be pruned from cache.
I guess, but it forces the server to store the document somewhere (presumably in RAM). It's much easier and cheaper in RAM to answer the POST with the formatted document, and you also spare complexity client-side (only a single HTTP call and only a single location for error handling). But yes, it would be a possibility.
... The HTML Web works because the "smart client" is a human driving the browser. (Or a dumb crawler that doesn't care what it gets.) I don't see how it's at all related to APIs driven by software.
And the HTML Web is NOT RESTful. Plenty of sites return different results for a URL, break links, have non-idempotent GET, don't return the created item's URL on POST, etc.
So when people talk like this about API-driven stuff, it sounds like UDDI or some magic dream. Can you draw a direct line to what kind of code is gonna be written? Or is this like a "well if we invent AI-like stuff then it'd be nice because AI won't be able to figure out RPC?" Maybe I'm being dumb and unimaginative.
But there's a vast network of services, far bigger than all the RPC APIs out there, that isn't like that. Where clients can connect to different services - even services made years after them, with functionality they couldn't have anticipated - without having to be tailored to them. Where the user can switch the provider of a specific service without having to switch clients, because the protocols are standard and compatible.
I'm talking, of course, about the HTML Web. Where people implement RESTful services without even knowing what they are, just because following a standard is just painfully obvious.
REST is the way we can implement something better; instead of dumb clients, we can have smart agents that interact with the rest of the web as browsers now do, but without the user hand-holding it. And gradually switching RPC to REST is the only way to accomplish that.