Hot answers tagged

63

Absolutely. For starters, you never know that somebody hasn't hacked into your connection and the reply you receive doesn't come from the API at all. And some time in the last two weeks I think Facebook changed an API without notice, which caused lots of iOS apps to crash. If someone had verified the reply, the API would have failed, but without crashing ...


39

Somebody else's API is your external interface. You shouldn't blindly trust anything that crosses that boundary. Your future debuggers will thank you for not propagating the other system's errors into yours.


17

Is your API-boundary also a trust-boundary? As you are communicating with a remote system, that's nearly a certainty. Even if the remote system itself might be trusted, the medium might not be. Failure to successfully and consistently verify all untrusted data may result in a crash in the best case, to silent hostile takeover at the worst. Is the API ...


3

Yes, but in most cases that should not be your personal concern. For most languages there are parsers that parse a native JSON (or whatever your transfer language is) response into your internal objects. They come with all the options to consider different writing style, understand corner cases, escape characters, special character encodings etc. Their ...


3

Absolutely. We have been caught out by this with Microsoft APIs, for example, and we were not even set up to log that in our Azure function application. So all we saw was that requests to our endpoints failed. It changed without any warning between hand testing / UAT and actual live use of our application. Our unit tests still worked of course, because they ...


3

Paranoid or not depends on how robust your software must be. I think, if your checks have minimal extra implementation costs then they are ok. Example: if you communicate with services through XML the structural verification can be done through an XSD schema. in Java/C# you can have guard statements that throw an exception, if the API contract is broken ...


3

Your validation shouldn't be to restrictive. There is the "tolerant reader" pattern. It means that you should be as tolerant as possible, when consuming data from other services. On the other side, there is the "Magnanimous Writer" pattern. Together, they help to produce more robust communication systems. For example, in a JSON based interface, you ...


2

Where to store Helper classes and what naming conventions to use is largely a matter of taste. There is no consensus; some developers consider Helper classes an anti-pattern and don't use them at all. The general principles I follow: Put the Helper class in a namespace or folder that is consistent with its scope (i.e. that Helper class is used throughout ...


1

You Require an API. This is a server at a well know ip/domain name that the mobile/web app/desktop app can contact via a network protocol such as HTTPS to retrieve data, and submit updates/requests. You may also need to create a task manager for performing offline processing as requested/needed by the API. This isn't for quick tasks such as saving data to ...


1

You can define you element first as a const/var or whatever. Then you access the element's attributes with element.attributes and iterate through your attributes like so: const element = document.getElementById('question'); ReactDOM.render( <Question {...element.attributes} />, element ); You can access the attributes with this.props If ...


Only top voted, non community-wiki answers of a minimum length are eligible