Should I validate API response on the client?

Question

Let's say I have an application which uses RESTFUL API. For example: I'm sending requests to the endpoint: "/products" and I'm receiving some response in the JSON format. Then, I'm using that data in my SPA application.

After sometime response's shape has been changed. I was not informed about that fact. As a result, my SPA application crashed. After change, some of the properties that I was using in my application were missing in the API response. I can prevent such a situation, when I would validate every response in my SPA application and put some placeholder value when it's missing in the response. But that may cause some performance issues.

Anyway, is a good practice to put API response validation on the client side?

Answer 1

I think the problem you are having doesn't really have to do with validation, but it has to do with your server upgrading in a non-backwards compatible way. What you need is probably a better way to handle updates.

I don't think occasionally downloading a schema and blindly filling in missing properties is the way to go. Can you build your service so it has some backwards compatibility? If you do have to break backwards compatibility, do you have a good reason and is there a sane way for the client to support it or do you need to update the client?

If you control server and client, a strategy that has worked for me was:

1. Don't do breaking changes right away. First update the server to then new version and in a later update stop supporting a previous version.
2. Clients can occasionally check which versions a server supports. If they find out that the server has dropped support for a version the client uses, update the client. (maybe just a refresh?)

But this is pretty broad. Not sure exactly how much this will help you as it's pretty situation-dependent.