11 ms·
Why is REST so popular? Because it's easy to implement and works for lots of use cases. I'm sorry that you found places it doesn't, but in the real world, hav
by bbarn 9y ago
Why is REST so popular? Because it's easy to implement and works for lots of use cases. I'm sorry that you found places it doesn't, but in the real world, having been through that SOAP pain it's being compared to, I'd say there's not even a comparison. Everyone seems to want to find a reason to dislike product/technology/feature X but in this case, X is just better than anything we've had for a 90% adoption case.
What is with medium.com? Why is it so many links to this site are full of hateful hipsteresque opinions looking to sound smarter and more insightful than they actually are?
- andrei_says_ 9y agoI think “hipsteresque opinions looking to sound smarter and more insightful than they actually are” is a very good definition for much of Medium’s content. It may have to do with the platform being used by individuals trying to create a brand of themselves, resulting in a high percentage of sensationalist and controversial posts. Along with the necessity to write on a regular basis.
- speedplane 9y agoProgramming Paradigm Becomes Popular B/C it gets stuff done --> left: it gets stuff done because it's smarter right: it's bad for you, it's actually getting less done middle: didn't read all that stuff, busy getting stuff done.
- ern 9y agodidn't read all that stuff, busy getting stuff done. I agree with this. When I end up on a new project and I'm not the lead, and there is a lead who is pedantic regarding how they want their URLs crafted (or wants to implement a complicated query pattern, or introduce an extra layer of objects to satisfy an abstract notion of purity), I'll just go with the flow. Accidental complexity, pattern seeking and cargo-culting are personality traits of many programmers, and I've come to the conclusion that its best to accept this, and get on with the job of actually delivering value.
- w0utert 9y agoCouldn’t agree more. I guess this is one of these insights that come with experience ;-)
- Yokohiii 9y agoInteresting viewpoint. But I am concerned that my mental capabilities can contain every brainfart that a misguided but smart person has.
- nine_k 9y agoThe problem becomes evident when you return to the results so the flow a year later to change something, and wish you were more mindful when getting things done. Cargo cults are not good. Finding and adhering to regular patters that logically underlie what you do saves time and mental effort, while also preventing certain classes of errors. (No, these are not GoF design patterns.)
- ern 9y agoI’m certainly not advocating spaghetti code, balls of mud, or a thoughtless lack of architecture. What I’m specifically referring to is wilful anti-pragmatism that betrays a sort of insecurity...it’s hard to define but easier to recognize. Finding the balance between pointless over-engineering and rigidity on one hand, and good software design on the other, consistently, is what seems to distinguish great programmers I’ve worked with, from those who are “just” very good. But, like I said, it often isn’t worth the trouble fighting about these things, even when we see them, and getting on with the job is more important than ensnaring oneself in religious debates on projects.
- seanp2k2 9y agoYou might like http://jsonapi.org http://jsonapi.org which defines a standard that is fairly sane.
- Yokohiii 9y agoleft: optimist right: sceptic middle: opportunist Having shitty paradigm is certainly better than having none at all. But at some point we have to evolve.
- LaGrange 9y agome: already groaning at the thought of fixing stuff after that one who didn't "read all that stuff," the "left", and thankfully the right was too busy pontificating to do anything so there's no fixing to be done. Read. The. Damn. Stuff.
- speedplane 9y agoMuch easier to fix other people's code if they never got the chance to write it in the first place.
- DarkCrusader2 9y agoI avoid medium posts as much as possible. Everyone is an expert on there with very strong opinions telling me how every technology older than 2 years and not written in javascript is obsolete/dead/not the right way/new <insert a dead technology>. And what's with the UI on their publications. They take up top 25% of the screen with the branding and navbar and bottom 10% asking me to sign in and both sticks on the screen. Who approved that?
- peshooo 9y agoI use the stylish add-on for Firefox and remove the bars. https://userstyles.org/styles/browse?search_terms=medium.com https://userstyles.org/styles/browse?search_terms=medium.com
- dgelks 9y agoThanks for this - Stylish add-on for chrome also works nicely too!
- unexistance 9y agoalternatively, use a bookmarklet to remove floating div... name the such as '1. rm float' then, it's only alt-B -> 1 away, in Firefox
- jimnotgym 9y agoFirefox reading view could have been invented for Medium! It doesn't make the articles any better though. Personally I will keep using REST. If I ever find something is too CPU or network hungry with http/JSON I will take a look at a binary protocol. For me REST has opened up the world of web applications to simple integrations. It is what makes simple, single use case web apps useful.
- DarkCrusader2 9y agoExactly. It doesn't have to be one or the other. Why can't they both be suitable for different use cases.
- 9y ago
- felipelemos 9y agoAnd REST is easier to debug. This make a huge difference when you have a big and complex system.
- harryf 9y agoAnd caching is easy to implement independently of the API using a proxy
- lfischer 9y agoHow exactly do you think REST is easier to debug and what alternatives are you comparing it to?
- ivan_gammel 9y agoCrafting REST request with JSON payload is significantly easier than doing that with SOAP (or, rest it in peace, CORBA).
- ern 9y agoI don't mind a loose JSON REST-ish API, where everything is a GET, POST or (maybe) a PUT, with explicit endpoints to resolve ambiguities. Once people start exhibiting excruciating pedantry in designing their APIs, I'll switch off somewhat.
- deeringc 9y agoThe author was comparing REST to json-rpc. Nowhere in the article does he propose that people use SOA or CORBA.
- ivan_gammel 9y agoThere's no difference between debugging REST and JSON-RPC over HTTP, so there's no point to compare them. The other alternatives, that I've mentioned, are less easy to debug.
- 0x445442 9y ago
- qaq 9y agoBecause they drive traffic ?
- marklgr 9y agoI happen to have worked with the system author coded/maintained. We're not in touch and I'm not here to defend him, but he's no hipster. Rather, he had to integrate a lot of heterogeneous services, as that system was acting like a hub between many departments in the company, with various tech skills and resources. If anything, I suspect he's more kind of unsatisfied by changes that he deemed unnecessary. As a note aside, the xmlrpc endpoints of the aforementioned system worked fine and saved us time.
- regularfry 9y agoXmlrpc is incredibly underappreciated.
- Marazan 9y agoXmlrpc is simple and it works. Xmlrpc is soap without the bullshit. I built lots of personal apps that were flash/flex front ends that talked to python backends over xmlrpc to quickly whip up his for my python aps
- dboreham 9y agobtw SOAP was supposed to be "xmprpc standardized" I remember well the meeting when things started to go off track...
- goliatone 9y agoIm actually curious now that you mention it but don’t expand on it. Was the road to hell really paved with good intentions?
- dboreham 9y agoI don't remember the history prior to the meeting well enough today to give an authoritative version. So for fear of getting some of it wrong I will say nothing. However, I'll say that the answer to your question is "no".
- Dowwie 9y agoYou're probably spending too much time reading tech blogs.
- mariocesar 9y agoBecause there is no "booo" button. Every post in medium just have Likes or none, you can like or comment just that, making a critical comment is to much for most of the users that just want to say "I disagree" If medium has some kind of down vote, it will regulate itself a lot more, and users that disagree will not have to go to make a comment and expose themselves being critical. Right now is full of "Content Hackers" trying to make reputation.
- mannykannot 9y agoSo long as an article makes a reasonable attempt to present a viewpoint, downvoting does not add anything to the issue. If you disagree, upvote those replies that you agree with (unfortunately, Medium makes that more complicated than is should be.) If no-one can be bothered to say what's wrong with the article, maybe there isn't much wrong with it. For example, xmlrpc has been recommended in comments as alternatives to consider. Maybe what's wrong with Medium is that the informative replies are on HN... (to be fair, grpc is mentioned on Medium.)
- deleted 9y ago[deleted]
- prepend 9y agoHate gets more clicks than producing. Twist on “easier to destroy than create.”
- bvrmn 9y ago> Why is REST so popular? REST is not popular, there are only a few RESTful public API in the wild. The rest (unavoidable pun, sorry) are simple HTTP APIs with JSON serialization which maps with various degree of coupling to internal data layer. The main cause you don't need REST limitations to achieve same goals. OP has strong opinion about why we need to reimplement rpc over http every time for every application and write clients for every popular platform to be able to consume it. Every time I use REST from any google cloud api, my hair is moving and you definitely will have nightmares if you look into their python client code.
- Cyphase 9y ago> The rest (unavoidable pun, sorry) ... The remainder.
- BerislavLopac 9y agoGood name for a REST library. ;-)
- goostavos 9y agoLink to these "actual" RESTful public APIs? I've been curious to see one (for years). Everyone talks about how this REST service is being done wrong, but few will link to services being done "right".
- karmajunkie 9y agoThis is the no-true-scotsman fallacy applied to REST. In point of fact, if REST has been around for nearly 17 years and there are so few of these APIs in the wild, then its been incredibly unsuccessful in its aims. The truth is that these sites are, in fact, RESTful and that REST is just mediocre at what it professes to do. The requirement to treat all operations as resources + HTTP verbs is the primary leaky abstraction that everyone seems to want to gloss over.
- calimac 9y agoGreat point. Someone needed to bring the long winded medium post to reality. I cringe at medium links.
- thinkpad20 9y agoThe article laid out a detailed explanation of shortcomings of REST. You might not agree with everything in it, but you offer no real rebuttal, instead dismissing it as a “hateful hipsteresque opinion,” without acknowledging any of the actual criticisms the author gave. This strikes me as unfair, haughty and lazy.
- mistermann 9y agoThere's quite a "circle the wagons" mentality common in programming nowadays, following politics lead I suppose.
- thehardsphere 9y agoNah, that was in programming well before politics. They can have the same root cause though: someone's identity feeling threatened.
- sergiotapia 9y agoIt's full of click-bait because of the opportunity for articles to go viral. Spread is built into the platform, so you have people writing the most click-bait articles possible.
- coldtea 9y ago>Why is REST so popular? Because it's easy to implement and works for lots of use cases. Could have given the exact same non-argument for SOAP -- which in its time dominated corporate services. Whether it's "easy to implement and works for lots of use cases", it's a moot point if there would be something even easier to implement and worked even better for real use cases. Why stop at "easy" when you can have easier AND more coherent? Besides, REST is anything like easy. Case in point, almost nobody ever correctly implemented the original REST spec -- that's why everybody calls their implementations "REST-ful", they are some loosely inspired deviations that cargo cult a lot of useless junk. Supposedly the "real illuminated REST" (like real communism) doesn't even concern HTTP, it's a philosophy beyond web services. And yet's it's all the web related garbage part of the introductory examples that everybody follows (or tries to).
- parasubvert 9y ago“Real illuminated REST”? The REST spec? It’s an architectural style defined by Roy Fielding’s thesis (who also was the editor of HTTP/1.1 RFC). It attempted to describe the Web’s architecture in neutral terms and how it was derived by combining previous styles. Some people took this and crafted a quasi religion out of it, but that’s partly because vendors in 2002 were all lined up trying to replace the web with a CORBA equivalent and then almost succeeded with SOAP/WS-*. People got strident to fight the dollars that were lined up. It’s easy to forget there was no powerful web/internet community with social media and blogging platforms in those days, it was all mailing lists and a couple of conferences vs. Marketing budgets, sales teams, and agenda-wielding engineers on standards bodies from Microsoft, IBM, BEA, Sun, HP, etc. All RESTful means is that something is attempting to conform to the style. There never was a spec.
- coldtea 9y ago>It’s an architectural style defined by Roy Fielding’s thesis (who also was the editor of HTTP/1.1 RFC). It attempted to describe the Web’s architecture in neutral terms and how it was derived by combining previous styles. It's application for what are essentially RPC needs is which I consider cargo cult.
- 9y ago
- jimnotgym 9y ago> What is it with Medium.com The people you describe used to have blogs with crappy Wordpress themes that barely got noticed by Google, now they are on a big site so get discovered I guess?
- cptskippy 9y ago> that SOAP pain The pain you're referring to is relative to the language you used and when you touched it. SOAP is a comprehensive and we'll defined specification and when implemented properly you forget it's there because it just works. After about 2003 major vendors had their implementations locked down pretty well. In Visual Studio you just implement a basic controller and the remainder is configuration. If you wanted to consume something from Biztalk, PeopleSoft, any Oracle Product, or any other Enterprise product you could just add a service reference to a WSDL URI and a tool would generate your interface classes and DTO classes for you in your language of choice. In the Open Source world things were very different. Whenever I would provide a service to be consumed by a vendor, I would provide reference implementations in C#, JAVA, Python, and PHP. I would spend about 15mins on C# and JAVA, then the rest of the day fiddling with Python and to a lesser extent PHP. PHP and Python have had SOAP libraries for a decade but they require considerably more effort to even consume SOAP. I have never tried to stand up a SOAP Service with them but I can't imagine it's any good. Around 2012 I remember working with a partner company that was using RAILS for their platform. It was an absolute nightmare for them to integrate with our existing SOAP service layer. SOAP protocol libraries were the least of their issues. No client certificate authentication in their HTTP libraries. No serious XML support. They wrote their own implementation from scratch.
- bvrmn 9y ago> I have never tried to stand up a SOAP Service with them but I can't imagine it's any good. Python has decent SOAP server implementation with one-to-one request/response schema modeling https://github.com/baverman/dropthesoap https://github.com/baverman/dropthesoap
- oneplane 9y agoWell, that's actually where the SOAP pain is: it used to be that you couldn't make any good use of it unless you were using walled-garden vendor software. A lot of people dislike Windows, Visual Studio and anything else made by Microsoft. Same goes for Oracle. So then you are left with everything else, which basically means: everything without SOAP, Enterprise editions of runtimes, service buses and the likes. There are a lot more developers out there not working for an enterprise and not using those tools. Especially the developers doing open source work or doing small scale work. While nowadays it's fairly easy to make a Java Spring Boot application consume and serve SOAP, with automated WSDL imports and all the WS-* specifics, this wasn't pretty much never the case with anything new and free (as in speech).
- nickbauman 9y agoREST allows you to make decisions about the http interaction out-of-band, where SOAP provides (and often requires) the ability to describe all decisions about types and parameterization and exception cases in-band. The REST way allowed one to get started with something small and simple that people could agree to just by talking it over together. With SOAP you had to make all those decisions up front and put it in the specification. I believe SOAP is so complex that it's an analog to CORBA/IDL. REST is (at least initially) simpler and less specific than SOAP. That's its strength.
- stevekemp 9y agoCORBA? That's a term that gave me a sudden flashback to debugging nightmares in the 90s.
- karmajunkie 9y ago> I believe SOAP is so complex that it's an analog to CORBA/IDL. SOAP was intended to facilitate the same programming model but more loosely coupled. So that's not at all far off. And for what it intended to be—a specification for machine-generated bindings and SDKs—it was quite successful. It just didn't make the usability leap over to web development that happens outside an IDE.
- tie_ 9y ago> ...having been through that SOAP pain it's being compared to, I'd say there's not even a comparison OK, that is indeed the most usual response to "Why REST?". The main reason why people like REST is "because SOAP". It's a false dichotomy that the industry has fallen for. Oh, yeah, and you can run the GETs directly in your browser/cURL. I like that part too, but it only gives you so much. REST is more of a philosophy, than a standard. Hence everyone does it differently, and you have no chance to use the same library to talk REST with multiple different services (unless you make that library an overcomplicated beast). XMLRPC? It's a universal standard, that is just a few pages long and everyone can grasp it in their lunch break. Nobody would complain that your API is not "XMLRPC enough". It works (almost) the same way everywhere. You can get the XMLRPC library that's been built in since Python 2.2 and be reasonably sure that you are going to be able to talk to a random modern XMLRPC API. You'd have other such libraries for every major language. Ditto for JSONRPC, if XML sounds too scary (though it doesn't really matter much - it's a mostly transparent implementation detail). I'd wish people would stop bringing up SOAP as an excuse for REST. Yes, it was worse, but that does not mean that REST is particularly good.
- deleted 9y ago[deleted]
- dsego 9y agoIt's an architectural style.
- chisleu 9y agoI thought that SOAP was great, in that the library handed remote executions without extra work. There are HA microservice and REST model libraries/clients that do it much easier and without XML :D You have to give it up to Colfer protobufs on zeromq and kafka :D edit: stray click GRPC is fun too. I miss my fiber interconnected compute though.
- deleted 9y ago[deleted]
- chiefalchemist 9y ago> "Everyone seems to want to find a reason to dislike product/technology/feature X..." Furthermore, and it's been this way for as long as I can remember, too many want a tool to be the perfect fit for every problem. That is, they pick up a screwdriver and then are shocked that it's not good for driving nails. There is no OSFA technology.
- nakovet 9y agoI don't get why the main thread is an attack to the blogging platform instead of a discussion on the topic. IMHO REST is not easy to implement, it's easy to say "oh... okay I think I've got it... let me try" but it's very hard to implement RESTful APIs and the author mention a few valid pain points. Simple use cases like: a user forgot their password, what the proper way of handling this case? A PATCH for a User based on ID? If the ID is a integer ID then you have to query user by email or username before you are able to request a new password, if the PATCH handles this case what other cases does it handle? Can a user request a new password and change their age at the same time, is this a valid case? How you structure your controller to route to these special cases, do you create a custom endpoint thus making your API less restful? One thing I like about GraphQL is this idea of mutations, in many cases they are analogous to RPC calls, `userForgotPassword(usernameOrEmail) -> forgotPasswordResult`.
- carc 9y ago> Why is REST so popular? You think this guy is a hateful hipster, but most of what he says probably resonates with most software vets. To me, it's mostly against the REST zealots who demand REST is done in a very particular manner. I've seen companies with a very stable, robust RPC framework that had a small faction of REST zealots who were extremely against it because it didn't do things according to REST. It didn't matter to them how stable it was or how well it worked. Also, REST is relatively not popular - what percentage of the world's APIs use REST do you think? TBH, you're the one coming off like the hateful hipster to me.
- dajt 9y agoI don't follow links to medium.com for that reason. I'm getting old and grumpy and medium.com posts seemed authored specifically to irritate me. I'm not part of the new world so I guess I don't feel at home there.