我有一个后勤问题：我正在尝试找出管理 API 与应用程序不同步的最佳方法。解释它的最好方法是用一个例子：
假设 MyApp 版本 1.0 发布到需要 first_name、last_name 和电子邮件的“submit_feedbacK”API。
然后我将 MyApp 2.0 版提交到 App Store。该版本旨在将名字、姓氏、性别和电子邮件发布到 API。所有这些都是 API 上的必填字段。
我遇到的问题： - 如果我在新应用上线之前更新 API，它将破坏 1.0 版 - 如果我等到 2.0 版上线并远程削弱 1.0，我必须正确计时。
我猜“正确答案”是维护两个不同的 API。但是，如果两个 API 都发布到同一个实时数据库，那就有点尴尬了。
有人对如何建模有建议吗？
这个问题可能与iOS 消费 API 设计有一些共同之处。
正确的答案肯定是提供两个 API（至少在用户调整的短时间内）。您不必同时维护两个版本，因为一旦发布了较新的版本，您就可以维护该版本，只需将旧版本提供给旧用户即可。您可能需要对其进行的唯一真正更改是安全补丁或重大问题。重大更改（例如您决定重组整个数据库）可能会导致旧版本不再工作，但是更新到较新的 API 版本应该设计为允许以前的版本仍然有效。
我链接到您的另一个问题给出了有关如何让您的应用程序的不同版本访问正确版本的 API 的答案。
另一个注意事项是，您可能更容易（取决于您使用的框架）将您的 API 设计为引擎或子应用程序，并将它们简单地安装在不同的端点。我知道这很容易在 Rails 中通过使用引擎实现，在 Node 和 Express 中使用 app.use() 和子应用程序。
我会使用 webservice/http 端点与您的应用程序进行通信。如果您更喜欢在应用程序的所有版本中维护相同的 URL，则在发送到服务器的所有请求/帖子中包含一个版本号，以便它知道如何处理它们。这也将使开发和测试更容易，因为新版本可以针对服务器上的新 API 进行测试。
因此，在您可以在 web 服务/服务器中调用的任何函数上，添加一个带有版本号的变量。一个 BYTE 应该就足够了，因为我认为一旦您达到相同功能的 256 个版本（如果有的话），您可以重新开始并“终止对 v1.0 的支持”。
一旦服务器接收到带有数据的请求/发布，您只需在服务器 API 中编写一个简单的开关/案例结构，以便支持适用于两个版本。
如果他们做类似的事情，但是例如。交换参数或其他东西，您可以处理所有这些服务器端，并且可以在解决方案的服务器部分维护 BAL/DAL（n 层结构）。
顺便提一句。我的回答不仅适用于 iOS 或智能设备，还适用于“正在进行中”的生产设置的客户端/服务器方法，其中所有内容都必须在线，同时仍在开发和维护中。
希望它是有道理的，否则，评论它，我将尝试进一步解释它。
仅供参考，我使用 CodeIgniter。我正在使用https://github.com/philsturgeon/codeigniter-restserver提供的 REST 控制器。我最终决定为每个版本设置不同的端点。基本上我会为每个版本检查一个新的存储库并将其放入一个唯一的目录中。（即http://www.mysite.com/1.0/api/method，http://www.mysite.com/1.1/api/method等）试图在一个代码库下维护多个版本的 API 只是听起来太吓人了。至少当我发布一个版本时，我会知道它是一成不变的，我不必担心会破坏它。（注意：我必须使用特殊的 .htaccess 调整来让多个 CodeIgniter 实例从同一个域运行。如果你愿意，我可以分享）