Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

nmeri17's avatar

How do I guarantee response integrity on a public facing API?

I am on a team of developers working on an API accessible to 3rd-party clients. An important fix may necessitate changing a variable name in the response body. A mischievious or unwitting team member may have the urge to update a model/data structure, to the detriment of unsuspecting consumers, who will end up with broken apps.

A friend suggested baking variable names into unit tests for those endpoints. The tests fail when conflicting information arrives. I wonder if it isn't impossible for developer to equally update the test parameters so his updates can merrily leave for the CI server.

Is this the standard practice? Is there a way to enforce avoidance of such situations?

0 likes
3 replies
nmeri17's avatar

I didn't quite follow the write up, no thanks to the author's writing style. But I picked up the part about unit changes (or the change log) reflecting in the router in order to foster backwards compatibility while keeping memory footprint minimal.

This seems to be only applicable to minor updates and patches. How does code based versioning work in terms of major releases aka breaking changes? Assume something drastic like replacing a field with a relationship object, or some other fundamental database refactor which would make maintaining both versions impossible.

Snapey's avatar

use tests to enforce compatibility going forward.

If your engineers maliciously change both the API and the tests then you are screwed whatever you do.

1 like

Please or to participate in this conversation.