Termékkezelés menü

Hey, I just wanted say that I am in exactly the same boat. Except, I'm not really a fan of HTTP either. I hate the dogmatic BS that REST has become even more than I hate what it was conceived as.

Thank you for putting words on my frustration!

The idea of REST (state passed via requests and not in persistent server-side sessions) is a really good idea that lends itself to all sorts of benefits for scalability and maintainability. The real tragedy is that this good idea, which should be protocol agnostic, has been tightly and inextricably bundled with HTTP and hypermedia (the horribly named, and extremely constrictive HATEOS, for example). What we end up with is a post about "I hate REST" complaining (with merit) almost exclusively about the limitations of HTTP. 

HTTP is problematic. In my mind, there should be 4 "standard" verbs that are clearly defined: CREATE, GET, UPDATE and DELETE, and any number of possible custom verbs for other purposes. Then a standard like CORS, instead of relying on the awkwardly-named OPTIONS verb for preflight checks (and servers implementing OPTIONS endpoints exclusively for use with CORS), could instead define it's own custom verb like CORSCHECK or whatever. Then a lot of your complaints would be resolved: The URL represents the noun and you supply whatever verb makes sense for you, and you can build very complicated systems without having to endlessly override and over-complicate the 4 basic verbs. HTTP wasn't very forward-thinking and I wish it was better.

As you point out, if everything you want to do could be distilled to granular operations on a resource it would be fine but that’s just not the case. REST approaches the dogma of religion. If it really were as simple as claims suggest it is the descriptions of it would not assert it’s benefits but demonstrate them. Advocacy of the benefits entail some of the most muddled logic and descriptions I’ve come across.

Certainly stateless APIs scale but so do http bindings for a web service. Nothing special there. But abstraction is your friend and is as profound an advantage and means of simplification as is OO methodology. The rREST paradigm breaks down when you need to do anything more complex and perhaps transactional than operate on a single, granular, identifiable resource.

Protocol can be abstracted as can instancing, lifetime and more. Data communication can be rendered transparent and encapsulated rather than forcing yet another API into the mex with which one must build up from to implement a RESTful API. One gains simplicity by abstracting away transport and more and the only API becomes the one a given design calls for. Why should these matter or require one to grapple with anything at a low level.

Indeed there are implications in neglecting to use an underlying stateless protocol such as TCP/IP for a web service in the event of a connection loss but the best answer is not always to propagate the need for elemental operations to the client because that makes the client more complex. That’s suitable sometimes and not others. The need for state is a proverbial tar baby that sucks you into implementations that manage state such as session IDs. Scalability is not always needed and when it is state can be persisted on client systematically as is actually what’s happening in a so-called stateless and RESTful API.

As with anything you have to know what you’re doing and also the nature and limits of the problem you are trying to solve. In a RESTful application, if the client is is hosed you’re as screwed as you are as if state save on a server is lost.

RESTful APIs add a layer of client overhead in order to avoid having to take a more wholistic architectural look at trade offs that not all developers are equipped to do. That might be characterized as code more and think less.

Certainly RESTful APIs are one way to get the job done but few of it’s advocates are able to make the case for it because they’re unable to evaluate the trade offs. In their favor though is an ability to turn less experienced teams on a project and compensate for avoiding a few key approaches necessitating a thorough analysis of tradeoffs with more scut work which violates the DRY principle (I.e. Don’t Repeat Yourself).

Totally agree. The designers and adherents of REST have evidently never heard of the lambda calculus. That thing which describes the operations of all code, which is based upon the function call, a verb and a set of parameters. If we could think of a way to make that simple and elegant thing as hard as possible between remote systems, with as much impedance mismatch to overcome as we can shove in, so the simple act of receiving and responding to a remote procedure call could require as many unnecessary contortions as we could likely get, that would be REST. I don't get the resistance to URI path as verb, POST body as parameters, done. 'But it doesn't follow the REST paradigm!' No, it doesn't, because REST is stupid, whereas message passing via some agreed upon IDL just works.

You pinned it down, man. Implementing some specification is natural when you're programming, but add to that the REST dogma hanging over your head: it makes my job less enjoyable, i'd rather be creating stuff than to satisfy some REST architect wet dream while implementing specs, while trying to be creative about my software. 

I totally agree.

Word up

I think REST caught on because in theory it was supposed to be some simple standard that in theory is easy to get started with and work with, and hard to screw up. In theory! It’s also a reaction to SOAP where we had this complicated framework and envelope metadata and had to read through all this ugly XML and so on. What do people do when stuck with something they hate, but instinctively run in the opposite direction? 

As a programmer from the old days of procedural and basic OOP (before OO was ruined and turned into a very hard to read and understand mess by crazy people making it all complicated with multiple inheritance, interfaces, reflection, etc.) I thought that the point and beauty of creating your own functions and objects was that you were able to build a system where the code became readable like a natural language. If you wanted your program to do something, you wrote a command whose name reflected that thing. 

REST on the other hand, in trying to reduce everything to fit into this minimal “CRUD” data transport system way of looking at things, has pretty much ruined programming by making developers bend over backwards to fit their business logic and applications into something that had NO resemblance to any kind of natural language or easily understood way of thinking. We might as well be programming in assembly language. 

Instead of intellisense and easy to use tools we are back to using primative methods to test and develop. And forget integrated verbose documentation! Swagger is neat with being able to run example code, but it is limited to very simple samples (when it even works with your firewall) and how do you use it to document bigger workflows and processes, with diagrams and fancy formatting? 

I was never crazy about SOA to begin with, and I know people are using REST to built working useful software, but the methods and the code itself is laughable. I have to think that of the people who use it are young enough to not know any different! 

I agree REST sucks but I don't like to see verbs in the url either, I'd prefer JSON-RPC with an additional "service" member to assist with routing.

I was just searching for the "why" about rest and literally all I can find is the "when" and "how". No one talks about why it's beneficial. Then I came across this which sums up a few of my thoughts. Having said that, I think that REST is better than SOAP, and I don't feel that everything about REST is bad. I just think decision to use more than get and post is silly and artificial.

In the early days of development we started out telling the machines what to do at a very low level, hardwiring them. Soon we advanced to stored programs. The language was still primative low level machine code but it got a little more human friendly when we moved to assembly. Things took a big step forward with languages like FORTRAN and Pascal where we could name things using words that described what was happening. With basic OOP we got objects with properties and methods, where you really could model something in a way that the code itself began to read like an English (or insert natural language here) description of what your program is actually doing. Of course software developers could always find ways to write spaghetti code that is anything BUT easy to follow, but at least the languages provide a way to create software that models real world concepts, if you so desire. With REST and CRUD, all that is out the window. Software developers now think in terms of, and architect their applications and systems, around HTTP. It’s ridiculous. These people think they’re smart, but the truth is, it has ruined programming by turning it back into garbage that’s closer to assembler than English. 

10000% agree

Like Troy said, GET and POST are enough. POST have been created just because we needed to pass complex data. And if you read the spec of POST (HTTP1.0) you can read : "The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI". So the URI defines the semantic, not POST itself. In HTTP1.2 they begin to talk about creation of resources but the primary definition still exists.

So HTTP is just a "transport" protocol. It does not have to define any functional semantic, the semantic is in the URI and of course, because a software "do things", the URI should contains verbs.

If not, explain me how you ask for : findDeletedClients, searchClosedContracts, subscribeAContract, cancelAContract,....

A software is a set of data and actions, to talk to a software, you've to use data AND actions (verbs) 

I mean, from a practical point of view, if REST was supposed to make the communications between two independent systems easier, it failed, so far at least. Every single project where REST is involved I need to have endless discussions with the REST devs, the "documentations" is usually just bare bones and hides the real complexity. As a freelancer, I still need to provide quotes, so that becomes a lot harder aswell. I agree it's nice in theory, but rather shi**y in practice.

You are absolutelly right, but it seems most people move by trends not by thinking, microservices... Anyone? Huh...

When we write backend for mobile or desktop or SPA web app, we always get JSON in response. And in most cases, it makes sense to send JSON in request. 

What I am saying, that for such apps POST is enough. In rare case we CAN use GET but we don't need to.