9 ms·
RESTful considered harmful
- Propen 11y agoConsidered harmful considered harmful. Everything considered harmful. Harmful considered RESTful.
- ddalex 11y agoEverybody now writes a "considered harmful" article. I think it's the coder-hipsterish thing to do now. If you don't like it, don't use it.
- nine_k 11y agoWe need to buckle the trend and write more 'considered beneficial' posts! Partially this is already happening with <whatever>-awesome curated Github repos.
- vezzy-fnord 11y agoNow? The "considered harmful" essay is probably one of the most important early contributions to the field of computer science.
- ssebastianj 11y agoEverytime I read the "considered harmful" phrase, I ask myself "Considered harmful, by whom?"
- leeoniya 11y agodid you miss? > PS: Obligatory appendix: "Considered Harmful" Essays Considered Harmful. [1] [1] http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html
- bitwarrior 11y agoPretty much at a point where I immediately disregard "considered harmful" posts. Majority of the time its hyperbole and clickbait.
- myderpyaccount 11y agoI often wonder half amused, "What Would Dijkstra Do?", every time I see the phrase referenced. It's almost like harmful has lost meaning because of the complexity of the systems of which to it refers. Everything modern is ridiculously complex, even if it looks simple. You can't state that a single thing in a complex system is harmful without forcing yourself to re-evaluate the entire construction of the rest of the system, in which case you can either (A) determine that there is no alternative solution, or (B) the system must be altered in some other way (in which case now multiple things are equivalently harmful. Since (B) happens so frequently, this means many parts of every system are harmful precisely because the system isn't perfect yet (and every part can be minorly adjusted so long as other parts of the system are adjusted - and this latter part is never discussed (probably because the complexity involved is actually complex and someone else would be like 'dude, that's also harmful - your solution has side effects'))). If it was easy to implement new things people would do that instead of complaining. There's a good reason things are the way they are and not some other way.
- ominous 11y agowiki article on the phenomenon: https://en.wikipedia.org/wiki/Snowclone https://en.wikipedia.org/wiki/Snowclone There was a small discussion on the issue previously: https://news.ycombinator.com/item?id=9844117 https://news.ycombinator.com/item?id=9844117
- thaumaturgy 11y ago"Maybe if I use that famous phrase from the title of a famous document, people will take my sloppy draft more seriously."
- snarfy 11y agoArg. I hate the phrase. Unless you are Dijkstra you don't get to use it, IMO. Make up your own phrase. If your article is so profound and insightful your phrase will become the new jargon.
- dllthomas 11y agoEven Dijkstra didn't use it - the title was added by the editor.
- nine_k 11y agoA nice article, the key ideas can be scooped by reading headlines. REST has its limitations, but it has one nice advantage: it uses a very well-understood, totally ubiquitous, firewall-piercing protocol. I suppose it's still a huge win for any public-facing, moderate-load service. One can use compact (non-JSON) data representation and even compress headers to save bandwidth.
- dragonwriter 11y ago> REST has its limitations, but it has one nice advantage: it uses a very well-understood, totally ubiquitous, firewall-piercing protocol. REST is a protocol-independent architectural style. (And, even if you mean the kind of RPC over HTTP that is often misnamed REST, then using "a very well-understood, totally ubiquitous, firewall-piercing protocol" -- i.e., HTTP -- isn't really an advantage over the main things it is an alternative to, e.g., XML-RPC and SOAP-over-HTTP, which use the same "very well-understood, totally ubiquitous, firewall-piercing protocol.")
- nine_k 11y agoYou are technically correct, best kind of correct! I'd love to see a relatively non-obscure example of REST run over to a non-HTTP protocol. REST feels sort of natural over HTTP, with all these URIs and HTTP method verbs. XMLRPC has all the disadvantages of REST listed in the original article, but seemingly none of the advantages (like a logical, discoverable structure). Correct me if I'm wrong. SOAP indeed has advantages — it has WSDL! When done correctly, it's delightful to work with. It's complicated and enormously more bloated, though. When run over HTTP (that is, most of the time), SOAP suffers from the same transport- and connection-related disadvantages as REST over HTTP does.
- dragonwriter 11y ago> I'd love to see a relatively non-obscure example of REST run over to a non-HTTP protocol. HTTP itself is the prototypical example; it is REST over an unspecified lower-level transport protocol (usually, in practice, TCP/IP, but that's explicitly not required in the spec) in the same sense that REST APIs that we usually talk about are typically REST over HTTP.
- josephscott 11y ago<blockquote> Of course JSON has one (literally, one) tremendous advantage - it's human readable. </blockquote> I was surprised he didn't mention ease of use inside JavaScript.
- jpollock 11y agoYou're not supposed to eval the strings, that way leads to xss. Since you're supposed to parse it no matter what, there's no difference between JSON and any other format.
- Drakim 11y agoNot true. While you should indeed not eval the string, once you have properly parsed it, you get a structured collection of objects and arrays that is very regular JavaScript structures. XML cannot offer the same, you get some much more abstract representation can easily be "wrong" if you don't follow the format as you extend it with more values, objects and arrays.
- jflatow 11y agoNot really, browsers still provide native JSON parsing ability - which is faster (and easier to implement) than most other parsing you would write inside JavaScript.
- bwy 11y agoUmm. I have no clue how you can say this. In JavaScript, JSON is unquestionably the easiest format to use. It may or may not be the same to parse, say, JSON and XML. But how is xmlDoc=new DOMParser().parseFromString(booksXml); newatt=xmlDoc.createAttribute("edition"); newatt.nodeValue="first"; x=xmlDoc.getElementsByTagName("title"); x[0].setAttributeNode(newatt); as easy to use as JSON.parse(booksJson).title.edition = 'first' ?
- xrstf 11y agoModern browsers ship with `JSON.parse()`, but not with ProtocolBuffer.parse(), Thrift.parse() or BSON.parse(). This advantage has nothing to do with eval(), but rather that JSON is pretty much built-in everywhere nowadays.
- herge 11y agoMy 16 word rebuttal is: Shitty APIs are shitty, but shitty RESTful APIs are better than shitty SOAP/CORBA/etc apis.
- sigsergv 11y agoNope, because shitty REST usually is a translation of shitty SOAP/CORBA/etc.
- betenoire 11y agowha...? obviously not true
- sigsergv 11y agoREST is working with documents only, there is just no way to DO something (more than C/R/U/D), you need to map actions to some C/R/U/D and so on. That's a serious practical limitation.
- andrewstuart2 11y agoMore accurately, REST involves only transferring state. The tricky (but worthwhile IMO) part is modeling what you want to happen as the state transition or set of state transitions that it is.
- sigsergv 11y agoYes, and also REST does not eliminate real business concepts so you need constantly “convert” business/domain operations to REST CRUD, and this process takes too much resources. You can change business/domain of course, but I'm not sure it's suitable for everyone (API is just one of components among others). REST is conceptually really hard and requires almost military discipline.
- oldmanjay 11y ago
- richmarr 11y agoI belong to the static typing camp... REST, static/dynamic typing... all decisions like this are a cost trade-off. There aren't really two 'camps', there are just comfortable positions on a scale, places where people are acclimatised to the trade-offs by their experience.
- akoumjian 11y agoThis is such a non-issue. All you have to do is look at how successful RESTful APIs have been this decade. It's easy to consume, which is really the number one priority if you actually want anyone to use your API. Anyone who has built an API will tell you that REST gets you 80% of the way, and if you need some transactional business logic the world will not end if you add a few non-REST custom endpoints.
- mmilano 11y agoI was expecting to see an alternate suggestion for communication via client-side browser based JS apps.
- therealmarv 11y agotake a look at GraphQL https://www.youtube.com/watch?v=9sc8Pyc51uU https://www.youtube.com/watch?v=9sc8Pyc51uU it definitely solves design issues with RESTful APIs
- mands 11y agoJSON-RPC always works well and is quite simple. I often find it easier to just use JSON-RPC and clearly mark which methods are remote than to try and fit my remote semantics into correct HTTP verbs and status codes.
- sneak 11y agoI frequently wonder why json-rpc isn't more of a thing. I've always rather loved it.
- mands 11y agoI agree - JSON-RPC is simple to use, parse and understand. Plus I feel it makes more sense when you are triggering computations remotely rather than querying. At StackHut (http://www.stackhut.com http://www.stackhut.com) we're hacking on a platform that takes code you've written and hosts the API in the cloud over JSON-RPC. We think it's pretty cool and would love to hear from others doing interesting stuff with JSON-RPC.
- maxehmookau 11y agoHarmful to whom? You don't like REST. That's cool. REST has actually been very useful.
- vezzy-fnord 11y agoThis is kind of a thought-terminating cliche, though. Not that a lot of "considered harmful" essays necessarily have much substance, but actually pointing out that a lot of popular software is architected in a harmful manner and reinforces negative feedback loops, antipatterns and wrong conceptual frameworks is a legitimate thing to say in general. Dismissing such criticisms with "It works for me," "If you don't like it, don't use it," or "Who cares about X? I just want my Y to work!" is annoying and by definition anathema to any technical discourse. They're vapid emotional arguments.
- cholantesh 11y agoI would rather see a discussion of how a potentially destructive mechanism could be improved, particularly one as ubiquitous as REST. But I imagine a lot of these essays are not particularly well thought out; they're just an expression of momentary frustration that the author won't hold a month or even a week after publishing.
- jflatow 11y agoI stopped drinking the REST cool aid years ago, for pretty much the same reasons. It's not that HTTP APIs aren't useful - of course they are - it's the religious adherence to REST doctrine that is harmful. I take the author's point to basically be, "do the simplest thing that makes sense for your use case, don't worry about how RESTful it is", which I totally agree with.
- moistgorilla 11y agoCan articles with the words "considered harmful" in the title (or the article itself for that matter) be banned? It's almost always a low effort way to get votes by taking a popular technology and finding some flaws to write an article on.
- jeremysmyth 11y agoNo. Downvote if it's low quality, upvote if it's good. Personally, "considered harmful" is in the "meh" category for me, but I'm not curating HN articles, nor is any other individual.
- andybak 11y agoIgnore the title and take each post on it's merits. Personally people complaining about 'considered harmful' irritates me more than said articles. I thought this article was OK - certainly good enough to skim read for 5 minutes. Neither an upvote nor a downvote from me.
- moistgorilla 11y agoThe problem with considered harmful I'm having is that so many low quality articles are using it in their titles and it really says nothing about the content other than somebody thinks some technology is bad.
- merb 11y agoRESTful doesn't mean "JSON" only. It never did and never will. People using RESTful APIs with XML. Also i don't get many things he is saying like: > multiple parameters for each criteria, e.g. age=10&name=John&company=Foo (but how to implement OR operator?) I mean seriously? How would one represent a filter in a GET URL... there aren't many solutions. Also CRUD by Design? What are you talking? REST is not a fucking standard, it's just a way to create your API, you are totally free, to use CRUD or not, your API's could still be within REST if you not use CRUD at all. You could even make REST APIs with GET and POST. Everything he writes has nothing todo with REST. It's just a design decision.
- andrewstuart2 11y agoRESTful also never meant HTTP. REST is literally just transferring resource state explicitly, via some mutually-understood representation of a resource. JSON just happens to be much more readable as well as pretty familiar for anybody who's written code in a C-like language, and especially familiar for JavaScript developers.
- jazzyk 11y ago>RESTful also never meant HTTP NOt in its original spirit, but it was developed in parallel with HTTP 1.1 (see https://en.wikipedia.org/wiki/Representational_state_transfer https://en.wikipedia.org/wiki/Representational_state_transfe...) and uses the same verbs (GET, POST, ..) as web browsers to transfer data. I agree with the posters who say that just using 4 verbs is CRUD-oriented and semantically just not rich enough to support often complex business operations.
- dragonwriter 11y ago> RESTful also never meant HTTP. Right. HTTP is a (the original and motivating, in fact) RESTful protocol, not a required lower-level protocol on which all RESTful protocols must rest.
- deleted 11y ago[deleted]
- 11y ago
- strictnein 11y ago> "By building all these levels of abstractions we forgot that web is really asynchronous" Uhh... nope. No one forgot that. Least of all the people he's chiding. Any decent Javascript / Front End Dev is acutely aware of this. Overall, this is perhaps the most unpersuasive clickbait I've read in a long time. It is amusing, though, to see a Java dev complain that REST isn't enterprisey enough. That's not a negative, good sir, that's a selling point.
- sigsergv 11y agoNot all business/domain logic is document-oriented. You can map any api to “documents” but result will be horrible usually. There is an excellent book — “RESTful Web Services Cookbook” by Subbu Allamaraju, it covers all aspects of practical REST API and trains very useful sense of REST applicability.
- muaddirac 11y ago> Talking about documentation, purists claim that the only piece of information API should expose is the root URI, e.g. www.example.com/api. Everything else, including allowed methods, resources, content types and documents should be discovered via HATEOAS. And if URIs are not officially documented but instead should be discovered, it implies we should not rely on hard-coded URIs in our code but instead traverse the resource tree every time we use such API. discoverable != must be discovered This is a misconception and criticism I used to have. However, it's a misunderstanding of the point of HATEOAS - the point isn't that you can't use hard-coded URIs, but that any given URI should be reachable by traversal from the root URI. In other words, it's fine to keep a bookmark to your favorite article, just make sure you can get to that article from the homepage, too. (I guess I would say modulo redirects as well)
- xwintermutex 11y agoI agree with his problems with status codes.
- batou 11y agoI agree with this to a point. I just built an API over HTTP, ignored all the REST rules and separated everything into commands and queries. Commands are POST and do something. Queries are GET and get something. I need to write this up. Schema is hell with JSON etc. I don't get how you can enforce something like this cleanly in a language like JavaScript under node.js or something without piles of assertions or some weird meta-format. I'm barely managing with an informal Also JSON is a crapfest for transferring data. Need something better than that over HTTP that is strongly typed with strong schema and has flexible binary formats other than whacking a base64 encoded string in an object or using multi-part mime. And then you're back at RPC and protobufs or something similar. Perhaps that's the answer.
- robinhowlett 11y agoAre you describing CQRS? http://martinfowler.com/bliki/CQRS.html http://martinfowler.com/bliki/CQRS.html
- batou 11y agoNo, CQS. CQRS is slightly more complicated and decouples everything via a service bus model along with a massive software ghetto lead by Udi Dahan who I personally despise. An excellent marketer but a poor engineer. I've cleaned up two companies who bought into that idea (event sourcing, service bus etc). Simply a command is something mutative. A query is something not mutative that returns information. There is no further specification other than that. It doesn't mandate a bus or event queue or publishing model nor whether or not the commands are synchronous or asynchronous.
- gregyoung4321 11y agoCQRS does not involve a service bus (though people like to sell them). This sounds like some people were led down very bad paths. Using event sourcing and a service bus together is frankly retarded. Greg
- skazka16 11y agoOur team is currently working on building a pretty big internal API from scratch. I took a look at some popular APIs (twitter, facebook, twilio, etc.) as a starting point. All of them has its own structure of the response, as well as the way you interact with those APIs, i.e. one may use `order` field to sort the resultset, while the other one prefers `sort_by` instead. There is definitely nothing wrong about that. But most of us like standards. We try to follow specifications as much as possible, at least to make things more predictable. Long story short - we ended up with http://jsonapi.org/ http://jsonapi.org/ - a complete specification for building JSON-based APIs. It supports such things as pagination, filtering, sorting, relationships, etc. All of us could implement it all very easily, but only God knows what is on the mind of an engineer, i.e. whether he likes /endpoint.json vs /endpoint?format=json.
- reklis 11y agoI actually agree with you on static-typing and am a huge fan of binary protocols but using "no standards" around anything is a weak argument that everybody needs to just stop. If you don't like the fact that there are no standards with a particular tech, go out there and MAKE SOME. Show people how to do it right, document it and propose it. Get some buy in. Don't just sit around going "oh woe is me, no standards"
- Yhippa 11y agoShort of the service provider giving you a library to access their code I prefer REST over SOAP for integration work I've done. REST in my experience forces better documentation and interaction between the service provider and client. I've worked with way too many SOAP services where some dev from 8 years ago wrote the service and nobody at the company wants to go anywhere near it to modify it. On top of that there is nearly zero documentation or if it exists it's very poorly done. With REST I feel I'm forced to interact with the creator which in my experience also drives better documentation. Because who wants to answer all of my usage questions :-) I have never run into HATEOAS in the wild but it sounds pretty cool. I hope to get to try out a service that implements that one day.
- clessg 11y agoUgh, can't read it because of the scrolling. Not sure what that's about.
- justizin 11y agoSince nobody can agree what RESTful is, and RESTful services tend not to follow any particular set of rules, indeed to the extent that most RESTful services aren't really RESTful, it's hard to get past the section titles in this as being anything other than an exhausted straw man.
- danpalmer 11y agoThe benefits of REST come when making public APIs that can be discovered with HATEOAS. People aren't doing that much yet, but I do hope it catches on, because we're not going to reach the next level of interaction between services until it (or something similar does). I think the title misses the point a little, or at least generalises too much. REST is not harmful, it's incredibly powerful when used for the right thing. However, REST is not the correct technology choice for internal or high performance APIs.
- clavalle 11y agoThis just in: one particular technique is not good for every use case! Most of these complaints boil down to REST is not complex enough to capture more complex interactions. But that is its strength -- yeah, there might be some tweaks to make but if you run into a RESTful interface it is easy to get your bearings. If you need something with more meat, pick something else. That said, shoehorning problems into a limited number of return codes with pre-existing specific meanings is an inherent problem with the whole REST approach, I'll give the author that. It is almost never a good fit.
- dpweb 11y agoIs HATEOAS generally considered good? I recently had to integrate to two corporate systems. One, the API used typical GET, POST, PUT, etc.. The second (before I knew the term applied to this) provided a single URL whose response was needed to describe the other operations. I remember instinctively hating the second. Now MY code has the burden of translating these into the specific calls. However, now we are version proofed.
- mcguire 11y ago"There are plenty of well-established binary protocols that are both easy to parse and use little memory, e.g. Protocol buffers, Avro or Thrift." I'd just like to point out that none of JSON, Protocol Buffers, Avro, or Thrift are protocols. They're serialization/unserialization formats/libraries/frameworks of greater or lesser tonnage. Whether they suck or not largely depends on how they're used; if you're tunnelling all of your communications over HTTP, you might want to do something HTTP-friendly. "Not to mention Swagger, the de facto standard for REST documentation, officially claims such approach is "not per design" - and sticks to fixed URIs." What? (One of the great downsides of REST is that most of the tools that claim to support RESTful designs, including JSR311 and apparently Swagger (I've never used it) simply don't.)