Considering change to the openapi schema as a BC break.

[joelwurtz]

Not really a feature, but more about the process of releasing new versions of api platform

When we upgrade api platform to new minor/patch versions like the last one (4.2.1 -> 4.2.2) we may have a lot of works in order to be able to use it.

In fact, we are using the openapi schema definition to generate javascript client, however change like this PR : #7397 or this one : #7398 update the name of definitions or others change that induce a new client being generated (new definition name by example) with new name / type and so it break the js app behind that.

Then a minor/patch upgrade can induce a lot of work on our side to be able to support it.

• Does our approach (generating a client from generated openapi from api platform) is wrong ?
• If not, should those changes be considered BC break and their should be a way to detect them ? (Like reproduce this process and checking that the typescript is OK ? i may be able to do a PR for that if you want)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[soyuka]

I don't think type generation is something that one should do as it tends to turn the API into a tightly-coupled RPC.

Basically, if we hardcode every data model into static types, we lose that 'independent evolvability' REST is built for (Section 5.1.5). The client becomes brittle because it’s expecting a specific database schema instead of following links (HATEOAS). If the server changes a path or a field, the generated client goes 'stale' immediately.

Maybe instead of generating every entity, we should have a client that understands link relationships (for example @api-platform/ld may be a good fit)?

Instead of defining Entities (which mirror the DB), we could use Zod to define the Resource Representation we actually need at the boundary. That way, we get strict type safety for the data we consume, but our code stays decoupled from the server's internal world. It avoids the 'RPC trap' while keeping everything bulletproof at runtime.

Do you have that many definitions on your API ? Maybe that you could just override the DefinitionNameFactory and use your own names to avoid such "breaking changes"?