如何提供 IPC API 向后兼容性

发布于 2024-07-25 17:33:51 字数 457 浏览 8 评论 0原文

我正在设计一个(类似 SOAP)进程间通信协议,用于通过网络进行函数调用。 我想确保旧客户端可以与新服务器通信。 想了想,似乎我唯一能做的就是:

  • 避免API的改变
  • 使得可以添加功能
  • 使得可以添加功能参数

但是,当服务器的功能彻底改变时,这还不够。 例如:

  • 必须从一个函数调用移动到另一个函数调用的参数。
  • 更改的参数类型,例如从整数更改为字符串。

我的问题是:可以在保持向后兼容的同时进行这种更改,还是唯一的选择就是不进行更改?

注意:我知道,我患有此处未发明综合症,但在我看来,这并不会使这个问题无效。

I am designing a (SOAP-like) inter-process communication protocol for making function calls over a network. I want to make sure an older client can talk to a newer server. After thinking over it for a while, it seems like the only thing I can do are:

  • avoiding API changes
  • make it possible to add functions
  • make it possible to add function parameters

However, when the server's functionality thoroughly changes, this isn't enough. For example:

  • a parameter that has to be moved from one function call to another.
  • a parameter type that changes, for example from an integer to a string.

My question is: can this kind of changes be made while staying backward compatible, or is the only option simply not to make them?

Note: I know, I am suffering from the not invented here syndrome, but in my opinion that doesn't invalidate this question.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

携君以终年 2024-08-01 17:33:51

您还没有确切说明您是如何实现 IPC 的,所以我可能会在这里做出一些糟糕的假设。 不管怎样,在我的脑海中,有几种方法可以解决这样的问题。

首先,关于参数顺序/类型更改的问题,您可以使用Python等动态语言来解决这个问题。

>>> def discriminant(a,b,c):
...     return b*b - 4*a*c

>>> discriminant(1,8,2)
56
>>> 
>>> discriminant (c=2, a=1, b=8)
56

Python 允许您使用命名参数,以便您可以按您喜欢的任何顺序命名变量,并且所有变量都是动态类型的。

解决排序问题的一种效率较低的方法可能是将所有参数作为字典传递(用 Python 编写,但可以适用于任何语言):

>>> def disc2(in_dict):
...     return in_dict['b']*in_dict['b'] - 4 * in_dict['a'] * in_dict['c']
... 
>>> d = dict(a=1, b=8, c=2)
>>> d
{'a': 1, 'c': 2, 'b': 8}
>>> disc2(d)
56

为了扩展这个想法,您还可以包含字典(或参数等)中的“版本”字段允许服务器根据传入的参数进行相应调整。 它不一定是字典,您也可以将版本字段放入包含 IPC 消息的数据包中。 这可能是一个人为的示例,但您也可以通过这种方式来解释丢失的字段。

>>> def disc3(d):
...     if d['version'] == 1: # original spec
...             return d['b'] * d['b'] - 4 * d['a'] * d['c']
...     else: # newer clients returning smaller values of c
...             return d['b'] * d['b'] - 4 * d['a'] * (2*d['c'])
... 
>>> d['version'] = 1
>>> disc3(d)
56
>>> d['version'] = 2
>>> disc3(d)
48

You haven't said exactly how you are implementing the IPC, so I might be making some poor assumptions here. Anyway, off the top of my head, there are a couple approaches to an issue like this.

First, regarding the point of parameter order/type changing, you can use a dynamic language like Python to get around this.

>>> def discriminant(a,b,c):
...     return b*b - 4*a*c

>>> discriminant(1,8,2)
56
>>> 
>>> discriminant (c=2, a=1, b=8)
56

Python allows you to use named parameters so that you can name variables in any order you like, and all variables are dynamically typed.

A less efficient approach to the ordering issue might be to pass all arguments in as a dictionary (written in Python, but can be adapted for whichever language):

>>> def disc2(in_dict):
...     return in_dict['b']*in_dict['b'] - 4 * in_dict['a'] * in_dict['c']
... 
>>> d = dict(a=1, b=8, c=2)
>>> d
{'a': 1, 'c': 2, 'b': 8}
>>> disc2(d)
56

To expand upon this idea, you could also contain a "version" field in your dictionary (or arguments, whatever) to allow the server to adjust accordingly to the incoming arguments. It doesn't have to be a dictionary, you could put a version field in the packet containing the IPC message as well. This might be a contrived example, but you could account for missing fields this way as well.

>>> def disc3(d):
...     if d['version'] == 1: # original spec
...             return d['b'] * d['b'] - 4 * d['a'] * d['c']
...     else: # newer clients returning smaller values of c
...             return d['b'] * d['b'] - 4 * d['a'] * (2*d['c'])
... 
>>> d['version'] = 1
>>> disc3(d)
56
>>> d['version'] = 2
>>> disc3(d)
48
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文