Timeline for Should a server "be lenient" in what it accepts and "discard faulty input silently"?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 14, 2012 at 12:25 | comment | added | Roman Starkov | Until someone else goes and implements your spec, only to find that the "robustness", that hundreds of clients have come to rely on, was not actually in the spec and has to be reverse-engineered... | |
| Jun 14, 2012 at 2:51 | comment | added | MarcLawrence | I see what your saying, and agree with the posters that a clean strict API/Service is the goal, but for better or worse I know I have added 'robustness' in one form or another to my services. Usually a value translation or two at the boundery. As long as the meaning is clear, the app knows how to process the message and no business rules are violated then adding robustness will help interoperability. | |
| Jun 13, 2012 at 17:36 | comment | added | Roman Starkov | But if you look at the answers here, everyone seems to agree that it only ever makes sense for UIs, i.e. the opposite of the original law. | |
| Jun 12, 2012 at 14:36 | history | answered | MarcLawrence | CC BY-SA 3.0 |