4 ms·
As someone who writes APIs for a living, this is often something interesting that I find a lot of division on: Say you have an API that is documented to accept
by madmax108 6y ago
As someone who writes APIs for a living, this is often something interesting that I find a lot of division on:
Say you have an API that is documented to accept params A,B or C i.e /v1/api?A=1&B=2&C=3
What should happen if you pass a param D to it? i.e. /v1/api?A=1&B=2&C=3&D=4
The two most common schools of thought are:
1) Ignore D
2) Throw an error
Both present their own problems, esp. when D may be closely related to A,B,C. Interesting how API design also tends to side with personal preferences for strictness or leniency
- rvnx 6y agoIn second case you may break other people's software because of your expectations on how the world should work. For example, Twitter pages not working if there is a fbclid parameter.
- selfhoster11 6y agoFBCLID and UTM tags are their own kind of craziness. They shouldn't have been present in the first place.
- taylodl 6y agoWhat's the old adage - be lenient in what you accept, be strict in what you produce? That ensures you can operate in a wide variety of scenarios with little to no interaction and coordination with the clients.
- deleted 6y ago[deleted]
- jcranmer 6y agoWhat if D is "always-use-utf8"? Or, in general, the option being requested is something that places much more stringent restrictions on semantics. There are two main reasons that users might validly use unknown options. The first is that it's an option with valid semantics in different versions/implementations of the protocol. The other is that you're reusing an option block for many API calls, and some of the options may not be relevant for some of those APIs. For the first use case, erroring out (or at least warning) is usually the superior solution: you don't know what it means, so you can't guarantee that you'll implement it correctly. For the latter use case, ignoring can be a safe solution. FWIW, there's been a pushback against Postel's Law (which is what the adage you cite is usually called) in more recent times. In particular, it should be emphasized that the law is generally most applicable when you're dealing with multiple interpretations of an ambiguous specification, and is least applicable when the standards are prescribing or proscribing particular behavior.
- wvenable 6y agoThe strict vs. lenient in this case also comes down to extensibility. HTML for example is notoriously forgiving and HTML parsers are quite complex because of it but it allowed HTML to be extended and improved upon while maintaining backwards compatibility. If the first web browser was extremely strict on the tags and structure it supported then web could not have evolved that way that it did.