Aug 31, 2018 · 1 min read
I disagree with the first suggestion. In the communication between the client and the server, there’s the facility of status codes. What you could return could be null (or corresponding to nullable from .NET) and then explain that the information was e.g. a bad request or whatever other reason there’s to be communicated.
The upside of it is that you don’t want your public API to be too informative for security reasons. However, in my view, the client should be able to rely on API never-ever-ever going poofy (but still be able to read from the status code how reliable info it gets).
So basically — the response is “I’ve got THIS” but there’s also a note saying “and it should be regarded in THAT way”.
