![]() This in addition to 10.0 => 10.0 connection. Consumer of version (V) understands the producer of version (V+1).Īnalogy: you want your new HDMI 10.0 streaming device to be able to connect to your old HDMI 9.0 TV. HDMI 10.0 was designed in a way so that clients (TVs) would be able to connect to old 9.0 producers (streaming devices).ĭata produced with a new version can be processed by consumers using the old version. HDMI 10.0 is thus backward compatible with HDMI 9.0. Consumer of version (V+1) understands the producer of version (V).Īnalogy: when you buy a shiny new TV with HDMI 10.0 you want to be able to connect it to your old streaming device supporting HDMI 9.0, in addition to HDMI 10.0 out devices. ![]() We can define 3 main compatibility types.Ĭonsumers using the new version can process data produced with the old version. So what changes exactly are breaking and non-breaking? To answer this we first need to understand different compatibility types. All versions, you might ask? We’ll answer this later. An API is backwards compatible if a client written against one version of that API will continue to work the same way against future versions of the API. The IT field usually refers to such non-breaking changes as “backward compatible” evolution. This holds for most APIs, whether JSON over HTTP or gRPC, standard-based (JSON Schema, OpenAPI) or freestyle, public or internal. It’s a universally accepted standard nowadays to evolve APIs in a way as not to break existing clients. Old clients must be able to read responses of the new server version.New server version must be able to read existing clients requests.Backward compatible API change should satisfy two constraints:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |