We need a consistent strategy for Studio apps with regards to URLs for frontend and also APIs. The API section is also interesting with regards to being able to expose our Commands / Queries automatically by configurable conventions.
However; public APIs are not to be taken lightly. Versioning matters as well. This should be consistent with SemVer.
Following the concept of SemVer we could for instance interpret it as follows:
Link it directly to the bounded contexts version
If exposing commands / queries as the public API on RESTful URLs - it means we need to version accordingly:
New commands or queries cause a Minor version number
Additional properties / changes causes a Major version number
We do not have the migration system in place. But effectively, we would now have to version the artifacts that are automatically being generated APIs from. This means migrators between different generations of an artifact such as a command or query. The API management system would need to deal with this as the bounded context itself should only care about its latest version.
Version would need to be part of the URL scheme for APIs.
We need a consistent strategy for Studio apps with regards to URLs for frontend and also APIs. The API section is also interesting with regards to being able to expose our Commands / Queries automatically by configurable conventions.
However; public APIs are not to be taken lightly. Versioning matters as well. This should be consistent with SemVer.
Following the concept of SemVer we could for instance interpret it as follows:
We do not have the migration system in place. But effectively, we would now have to version the artifacts that are automatically being generated APIs from. This means migrators between different generations of an artifact such as a command or query. The API management system would need to deal with this as the bounded context itself should only care about its latest version.
Version would need to be part of the URL scheme for APIs.
┆Issue is synchronized with this Asana task