3 ms·

you should never actually remove an api without a deprecation process. basically a message format is part of your api. actually in a microservice world your int

by merb 8y ago

you should never actually remove an api without a deprecation process. basically a message format is part of your api. actually in a microservice world your interfaces/api should be as stable as possible. if something gets changed, it needs to go trough a deprecation, that means not removing it until a certain amount of time.

NicoJuicy 8y ago
The accept header could fix this easily if no third parties are involved
NicoJuicy 8y ago
The accept header could fix this easily if no third parties are involved and if it's a rest like API protocol
- dragonwriter 8y ago
  The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions, which is a dev process issue, not a technical issue.
  - geezerjay 8y ago
    > The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions That assertion is not true. Media type API versioning is a well established technique.
  - NicoJuicy 8y ago
    Feature flags, just enable it. When all applications are adjusted, the accept-headers request a protobuff format in return. => Propagated everywhere except when a js ajax calls happens to the api-gateway.
xj9 8y ago
private apis exist for a reason. going through the deprecation cycle repeatedly sounds like a waste of time if you control all sides of the system. which is to say, not every interface needs to be a service boundary. you do need to keep versioned apis, but there is a cost to doing so.
- organsnyder 8y ago
  IMHO, part of a successful microservices program is treating your "private" APIs like your public ones, with SLAs, deprecation protocols, etc. Otherwise, you end up with tight coupling to the point that you should just go with a monolith.
  - galangalalgol 8y ago
    When you are still figuring out the problem space and message formats are being created removed extended and reverted several times a sprint, and you have already gone live with third parties depending on stable interfaces so that you cannot make the changes you need in a timely fashion, the warm arms of a purpose built monolith look particularly attractive.
    - organsnyder 8y ago
      Indeed. At that early stage of development, a monolith (or at least monolith-style practices, such as tight coupling between API providers and consumers) is definitely simpler and more efficient. But it wouldn't hurt to take steps from the beginning to make it easier to break the monolith apart when/if it becomes pragmatic to do so.
- geezerjay 8y ago
  All interfaces are service boundaries. The only difference is whether you controll all clients and servers or not. Either way, API versioning is a must and trivial to implement, and there is really no excuse to avoid it. All it takes is a single integration problem caused by versioning problemd to waste more time than it takes to implememt API versioning.
- 8y ago

by merb 8y ago

NicoJuicy 8y ago

The accept header could fix this easily if no third parties are involved

NicoJuicy 8y ago

The accept header could fix this easily if no third parties are involved and if it's a rest like API protocol

dragonwriter 8y ago
The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions, which is a dev process issue, not a technical issue.
- geezerjay 8y ago
  > The accept header is a mechanism for communicating formats you support; it doesn't do anything to address the problem of managing change to supported versions That assertion is not true. Media type API versioning is a well established technique.
- NicoJuicy 8y ago
  Feature flags, just enable it. When all applications are adjusted, the accept-headers request a protobuff format in return. => Propagated everywhere except when a js ajax calls happens to the api-gateway.

xj9 8y ago

private apis exist for a reason. going through the deprecation cycle repeatedly sounds like a waste of time if you control all sides of the system. which is to say, not every interface needs to be a service boundary. you do need to keep versioned apis, but there is a cost to doing so.

organsnyder 8y ago
IMHO, part of a successful microservices program is treating your "private" APIs like your public ones, with SLAs, deprecation protocols, etc. Otherwise, you end up with tight coupling to the point that you should just go with a monolith.
- galangalalgol 8y ago
  When you are still figuring out the problem space and message formats are being created removed extended and reverted several times a sprint, and you have already gone live with third parties depending on stable interfaces so that you cannot make the changes you need in a timely fashion, the warm arms of a purpose built monolith look particularly attractive.
  - organsnyder 8y ago
    Indeed. At that early stage of development, a monolith (or at least monolith-style practices, such as tight coupling between API providers and consumers) is definitely simpler and more efficient. But it wouldn't hurt to take steps from the beginning to make it easier to break the monolith apart when/if it becomes pragmatic to do so.
geezerjay 8y ago
All interfaces are service boundaries. The only difference is whether you controll all clients and servers or not. Either way, API versioning is a must and trivial to implement, and there is really no excuse to avoid it. All it takes is a single integration problem caused by versioning problemd to waste more time than it takes to implememt API versioning.
8y ago