我有一个逻辑问题：我试图找出管理与应用程序不同步的API的最佳方法。解释它最好的办法是用一个例子：管理iOS客户端/服务器应用程序更新的最佳方式
比方说MyApp的1.0版的帖子到需要名字，姓氏和电子邮件“submit_feedbacK” API。
然后，我将MyApp 2.0版提交给App Store。该版本旨在将first_name，last_name，gender和email发布到API。所有这些都是API的必填字段。
的问题，我有： - 如果我更新的API之前，新的应用程序是活的，这将打破1.0版 - 如果我等到2.0版是现场和远程削弱1.0，我必须要合理地安排它。
我会猜测'正确的答案'是维护两个不同的API。但是，如果两个API发布到同一个实时数据库，那会让事情变得有些尴尬。
有没有人有如何建模的建议？
此问题可能与iOS consuming API design有一些共同点。
正确的答案是肯定，以提供两个API（至少对于短的时间周期，而用户调节）。您不必同时维护两个版本，因为一旦发布较新的版本，您可以维护该版本，并为旧版用户提供旧版本。您可能需要做的唯一真正的改变是安全补丁或重大问题。重大更改（例如决定重新构建整个数据库）可能会导致旧版本无法正常工作，但更新的API版本应设计为允许以前的版本仍能正常工作。
另一个问题我联系你让你如何能有不同的版本，您的应用程序访问API的正确版本的答案。
另一个需要注意的是，它可能会容易些（这取决于你使用的是什么框架）来设计你的API，作为发动机或subapps，并简单地在不同的端点安装它们。我知道这很容易在Rails中通过使用引擎来实现，而在使用app.use（）的Node中通过子应用程序实现。
你知道在codeigniter中做到这一点吗？我正在考虑让每个api版本扩展旧版本，并只修改必要的内容。 –
不，我不知道。我没有使用CodeIgniter，但谷歌可能是你的朋友。 –
我会使用web服务/ http端点与您的应用程序进行通信。如果您在所有版本的应用程序中都保留相同的URL，请在服务器的所有请求/帖子中包含版本号，以便知道如何处理它们。这也将使开发和测试更容易，因为新版本可以针对服务器上的新API进行测试。所以，在任何功能
你可以在Web服务/服务器调用添加一个变量，版本号。一个BYTE应该足够了，因为我认为一旦你点击256个版本的相同功能（如果有的话），你可以重新开始并“杀死对v1.0的支持”。
一旦服务器接收到一个请求/后的数据，你可以只编写服务器API中的一个简单的开关/箱结构，支持两个版本的作品。
如果他们做类似的，但例如。交换参数或某物，您可以处理所有这些服务器，并且可以在解决方案的服务器部分维护BAL/DAL（n层结构）。
Btw。我的回答不仅仅是针对iOS或智能设备，而是一种适合“正在进行中”生产环境的客户端/服务器方法，在这种方式中，所有内容都必须在线，同时仍在开发和维护中。
希望它是有道理的，否则，对它进行评论，我会试着进一步解释它。
只是FYI，我使用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实例，我可以分享它，如果你喜欢的话）
你是说当你发布一个版本（比如2.0）时，你有效地将你的2.0分成2.1的新回购版？这种方法似乎给出了与子应用程序/引擎 –
类似的最终结果。我想尽量保持它作为一个大的代码库，但我提出的问题是：当我有这个API的100个版本（1.0.0,1.0.1,1.0.2,1.1.0等），做我真的想要在一个巨大的代码库中拥有所有这些版本？简单的答案是否定的 - 那将是一场噩梦。更好的做法是分离每个API并将其放在一边，这样我就不用担心会丢失它。每个应用程序版本都可以指向自己的特定API，而不用担心之前版本或将来的版本，除非我故意禁用并强制人员迁移到最新的应用程序。 – Anthony
版本控制数据库仍然是一个问题，但我发现几乎所有的数据库更改都添加了列。没有多少改变我已经完成的结构。如果是这样的话，那么现在是时候考虑改变一种新的模型，比如“user_v2”，并将旧数据迁移到新结构。任何人，那是我的方法。 – Anthony
我相信总体思路是尝试设计API和数据库结构它不会需要一段时间的突破性变化，以最大限度地减少总的尴尬。如果“性别”的价值在1.0的整个生命周期中不是绝对必要的，那么你也许可以在没有更新但尚未在版本转换期间提交它的用户的情况下做到这一点。 – millimoose
确实如此 - 如果没有提供值，新字段也可以默认为“男性”，因为传统应用程序不会提供该值。我想我更关心复杂的变化，就像一个概念需要重新接近一样。但正如你所说，如果重大改变很少见，其余的可能会通过停工通知来解决。我也只记得可以选择应用程序何时上线，这样可以帮助控制更新。无论如何，感谢您的反馈！ – Anthony