How to work with/around an API that does not return errors?

Question

I am currently working on a project which requires data fetching from a 3rd party closed API (over SOAP).

Currently I'm in a situation where I have to do argument and data validation inside our application code, because the mentioned 3rd party API does not return anything relating to errors. Examples:

1. Request something with a malformed query arg (e.g. 'helloworld' instead of 12345): API returns null, hence not telling me what actually broke the request.

2. Request with no query args, while the API expects some args: API returns null, so I'm again in the dark about what is going on.

3. The API can return a collection of data, or a single piece of data. How it handles "no data found": returns null like in all those error cases. This way I do not know whether there actually is nothing to find or whether the API broke again.

I've been trying various things and mapping out what works and what does not. I have got some example request responses from the API provider so at least I know what successful request responses look like.

Are there any good ways to handle situations like these when I just can't ask the API provider to implement proper error handling or similar approaches?

Should I just continue experimenting and wasting time while implementing the validation logic inside our application logic (which should then be abstracted in case the API itself changes or is dumped)?

(I posted this to SE Programmers instead of SO as this is not about a specific technical implementation detail, but about a way of handling the issue in general.)

Answer 1

I've implemented and used a "forgiving" API similar to what you're describing. But, it was forgiving only for read-type operations. And the reason was pretty simple: The underlying API (MySQL) was forgiving.

If you connect to a MySQL database, for instance, you might think the only "valid" way to select a record by it's INT PK is to give it an INT:

mysql> select * from users where user_id=123;
Empty set (0.01 sec)

And if you get an empty set you'll just think, "Oh, there are no users with an ID of 123." But, you can also give MySQL a legit string:

mysql> select * from users where user_id='Uncle Bob';
Empty set (0.01 sec)

And MySQL doesn't care. It just says, "Let's see ... oh yeah! None of these integers matches 'Uncle Bob' ... so, that's an Empty set, son."

My API didn't get a validation error from the underlying API, so I never saw the need to "fabricate" one. And, in a way, it makes sense: If you're querying for data that matches malformed or invalid identifiers, the resulting set is just empty.

For read operations, if you want to give the user helpful hints, that's up to you. On the other hand, if the user doesn't already know what goes in the ID field, giving them hints is potentially wasted effort.

For write operations, an API that ignores invalid requests and fails to complain is arguably "broken." But, if that's the case, you could work with the "broken" API by following each PUT with a GET to verify the changes. It's not ideal, of course; but, it should solve the issue.

Answer 2

For this service call, one might want to implement verbose logging.

I assume there is various error handling in place. When an error occurs or null is returned, log everything in the request to and response back. Typically this type of information would go into a debug log, but for this case, I would promote it to your regular logging. Then, you can handle new cases or conditions as they come up.