On Mar 1 2020, at 5:11 pm, Jarek Potiuk <jarek.pot...@polidea.com> wrote: > At this point you immediately lose all the flexibility that comes with "code > first" approach: you released the API already and you are not supposed to > change how the API is designed, yet the design is by-product of the code so > it is very difficult to make sure it stays unchanged. You can still change > the internal implementation but the interface should be frozen anyway. It's > much easier if your API definition is your "source of truth" rather than code > IMHO.
This is a good point and convinces me - API spec first so that API changes/tweaks are deliberate sounds like a good way of doing this (whether its v1.1 or v2 is a decision that can be made later). Do we need to support multiple versions of API concurrently, or can we put any such requirement on the client(s)? And so long as we have good updating/change log for the API versions that seems not too hard a thing to manage. -Ash
