4 ms·
The orthodoxy (aka "standard") is there for a reason. It's very easy to shoot yourself in the foot. If you're only doing small-scale internal interop, especial
by mseebach 9y ago
The orthodoxy (aka "standard") is there for a reason. It's very easy to shoot yourself in the foot.
If you're only doing small-scale internal interop, especially where you control both ends of all connections, you don't need standards, just do whatever works, but if you have scale dreams, thinking about the rules (What is 'state'? How is it represented? Where?) and why they are there will save you from a lot of headache going forward.
- barrkel 9y agoYou need a standard within the ecosystem you play in, if only to reduce the amount of work integrating bits and pieces. For example, I work on an application that has reasonably tight integration between pagination on the front end and parameters / headers on the back end. Works quite well, particularly since we can control both ends. It's not completely ad-hoc - we chose one specific idiom for pagination that had reasonable support, but not necessarily the most widespread - and then extended it slightly when we needed a few operations that had no direct support (e.g. multi-delete, multi-update). But if you're integrating from everywhere, there's no upside on a unifying standard because any unifying standard will either have so many wrinkles, complexities and caveats to cover every special use case that nobody will implement it correctly or understand it correctly; or it will be ill-suited to many domains, forcing a poor mental model, increasing the probability of bugs and reducing extensibility.
- ams6110 9y agoSome http clients can only do GET and POST. If your API demands PUT, PATCH, or DELETE it may be less useful.