posts/2022/backward-compatible-change-api-web-rest-http/

[utterances-bot]

How to make your API backward compatible (Web, REST, HTTP, etc) :: EasyIT blog — Ivan Vaskevych personal blog

It’s a universally accepted standard nowadays to evolve APIs in a way as not to break existing clients. This holds for most APIs, whether JSON over HTTP or gRPC, standard-based (JSON Schema, OpenAPI) or freestyle, public or internal.

http://localhost:1313/posts/2022/backward-compatible-change-api-web-rest-http/

[IvanVas]

test

[farrault]

Hello Ivan, Nice post. In "JSON data format evolution" paragraph : "Adding a value to an enum string" is described as both forward and backward compatible. Is that what you mean ? Seems only backward for me. Because even if the client is coded defensively enough to succeed to read a response with an unkown enum value (which arguably breaks the previous contract), it can't know want to do with this additional value Regards

[IvanVas]

Hello Ivan, Nice post. In "JSON data format evolution" paragraph : "Adding a value to an enum string" is described as both forward and backward compatible. Is that what you mean ? Seems only backward for me. Because even if the client is coded defensively enough to succeed to read a response with an unkown enum value (which arguably breaks the previous contract), it can't know want to do with this additional value Regards

Yes, from the semantics PoV that's true, we might loose important use cases. But just in terms of schema the client seems to be able to decode the newer version just fine, given the proper logic for the unknown values.

I updated the text slightly to clarify.

[EnterIen]

Hello lvanVas, i really like diagrams in this post, can you share the drawing software?

[IvanVas]

Hello lvanVas, i really like diagrams in this post, can you share the drawing software?

https://github.com/excalidraw/excalidraw Great soft, highly recommend!