6 ms·
My 16 word rebuttal is: Shitty APIs are shitty, but shitty RESTful APIs are better than shitty SOAP/CORBA/etc apis.
by herge 11y ago
My 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 agoI'm amazed that you feel this way, because my experience is completely the opposite. Banging out the REST API portion of things is usually a mechanical wrapper around some business process in the systems I have been creating. CRUD comes into play with entity manipulation, of course, but that's only one facet and in my current case, not even the dominant one. In fact, I don't even know why you'd think you have to map business processes to CRUD at all. It almost seems like you have some religous belief about what REST actually is, much like how the article talks about "de facto" standards that are nothing of the sort. I suppose you have strange requirements or design impositions that make your life difficult, but I caution you against believing that your use case is universal because in my very real experience, none of your opinions are supportable.
- andrewstuart2 11y agoThat could be his experience, though. I've run into waaay too many APIs that call themselves RESTful and are just a collection of RPC endpoints with a method="..." query parameter plus named parameters. If I hadn't read Fielding's dissertation [1] I probably would have been lost in the weeds as to whatever the heck REST actually meant. [1] https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
- bakhy 11y agowell, next time i plan to write a shitty API, i know what to go with. thanks ;)
- herge 11y agoMan, if I could plan on writing shitty and non-shitty apis, I could just skip the shit ones and be a lot more successful in my work!
- bakhy 11y agoi know, right! ;) but seriously, who would make technology choices based on that reasoning? the thing should have it's merits, preferably for non-shitty software too. so it's not that i agree with everything the author said, i just think your rebuttal is not very good. where were your arguments anyway? to me, if it's shit, it's shit. but i do prefer shit of the "strongly typed" flavour. when dealing with shit, i'll take any automated help i can get. but even there, of course, we can talk about trade-offs, and not absolute truths.
- oldmanjay 11y agoEven that rebuttal is too specific. The article is mainly unsupported assertions of the correctness of the author's opinions, interspersed with whining about issues that are totally orthogonal to REST.