4 ms·
Having used “REST” for 10 years or so I can confidently say I’ve never used REST
by catmanjan 3y ago
Having used “REST” for 10 years or so I can confidently say I’ve never used REST
- the__alchemist 3y agoYea. I assume from the article it's an alias for an HTTP interface that usually uses JSON payloads. I use those in a few projects, both work and personal. Are they Rest? Maybe. They use Django REST framework. But I think of them and describe them as HTTP APIs.
- munk-a 3y agoWell, if we're being truthful, none of us use REST. We're all just cherry-picking the parts of it that work for our organizations... and that's absolutely fine. The programtic discoverability portion of REST always struck me as pretty poorly thought-out anyways.
- nesarkvechnep 3y agoYou use REST every day. HTML is REST. Yes, with HATEOAS.
- deleted 3y ago[deleted]
- munk-a 3y agoWell, not all of REST - the discoverability portion isn't supported by pretty much anyone (because, IMO, it's just not useful).
- the_gastropod 3y agoI think you missed the point. You 100% use it every day. You’re using it on this website right now. Your web browser shows you what actions you’re able to take against the HN api. Neat, huh?
- richbell 3y agoThe three common types of "REST" I have encountered in enterprise dev are: 1. Ancient XML/SOAP based APIs Frankenstiened to use JSON 2. Poorly implemented RPCs advertised as "JSON REST API", usually the entire thing either relies on POST requests but sometimes GET is used to make stateful changes. 3. Things that should obviously be RPC split into dozens of anemic JSON endpoints that the caller has to re-construct to get anything useful Incidently, my company's leadership got inspired by Amazon's API culture and made # of APIs a metric that teams must hit. The result is every single endpoint being deployed as a separate API, and teams blocking access to native vendor APIs so each operation can be republished as a new API. :)