Timeline for Should an API return calculated values that the consumer can calculate themselves?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 3, 2020 at 19:47 | comment | added | Christian Hackl | @Bogdan: As for your last point, it depends on the original semantics, which must be part of the API documentation. If the rule is fixed in the first place, then the API implementation cannot simply change; it would effectively be a new version of the API. If the rule is documented as implementation-dependent, then the question becomes moot, because in that case client validation is impossible anyway. | |
| Feb 3, 2020 at 19:45 | comment | added | Christian Hackl | @Bogdan: I suppose your trust comes from your personal experience with very well-implemented, robust APIs, and in that context, client-side validation becomes less of a concern. In contrast, the most expensive (in terms of real money spent) project I've ever worked on also had the worst API I've ever worked with as a client developer. It was a largely undocumented JSON REST API with funny stuff like fields whose semantics mysteriously depended on whether the identifier was lowercase or not (I think it was "Id" vs "id"). The client could not have survived without validation. | |
| Feb 3, 2020 at 19:12 | comment | added | Bogdan | @ChristianHackl: Another reason (besides trust) of why I would not validate the computed field in the client is what I mentioned in my answer to this post: if I add some validation on the client to check the field, and then the rules to compute the field change on the server side, the client will now (falsely) identify a perfectly valid rule change as an error in the response. You then have to change the client code to account for the new rule. As a client I shouldn't really care about that. | |
| Feb 3, 2020 at 19:09 | comment | added | Bogdan | @ChristianHackl: From what you said in your first comment I gathered that you think the client is somehow obligated to validate the computed field, just because it's a computed field. What I'm saying is, I would not do that unless I have reasons to do so. You ask would you verify that the price is positive? It depends if the price has ever been negative. If I have reasons to doubt the API, then I might put some checks in place to avoid displaying something weird to users because someone screwed up on the API. I trust the API unless proven otherwise. I don't eagerly validate the API responses | |
| Feb 3, 2020 at 14:40 | comment | added | Christian Hackl | @Bogdan: Where do you draw the line between error handling and "not trusting" the API? For example, would you verify that the price is positive? | |
| Feb 3, 2020 at 12:56 | comment | added | Stack Exchange Supports Israel | Example new rule: Buy 3 weeks and get your 4th week free! Daily price = $10, number of days = 28, total price = $210. | |
| Feb 3, 2020 at 9:25 | comment | added | Bogdan | @ChristianHackl: Error handling is one thing, not trusting the API you are calling and deciding to add code to double check for stuff is another. | |
| Feb 2, 2020 at 23:51 | comment | added | Christian Hackl | Whether the client or the API is more likely to get the computation wrong depends on many things. It is also not true in my experience that testing an API means that clients need not perform any error handling, unless you are dealing with an extremely stable and robust API, e.g. something provided by your own operating system. Additionally, you may eventually have no control over how the API is developed and tested, anyway. | |
| Feb 2, 2020 at 21:10 | comment | added | Bogdan | @ChristianHackl: Getting the computation wrong on the client is just as easy as getting it wrong on the server. Besides, this can easily be cought by the unit tests of the API. Having this field tested by the client might make it robust, as you say, but it also opens up a can of worms. If the client doesn't trust this field in the response, what else doesn't it trust? How far are you willing to go to complicate the client code just to check that the API does what it's supposed to do? | |
| Feb 2, 2020 at 19:08 | comment | added | Christian Hackl | One advantage of having client the compute the missing information is reducing the error space. Any redundancy is a possible inconsistency; you may actually make the client's life harder by providing additional information which can be logically derived from the basic information, because now in order to validate the API responses, a robust client will have to verify that the computed value is correct and will have to decide what to do if the information is inconsistent. | |
| Feb 2, 2020 at 16:54 | history | answered | Bogdan | CC BY-SA 4.0 |