3

我将为 Web 应用程序开发一个 iOS 应用程序。（网络应用程序使用代码点火器）

我将创建一个 iOS 应用程序将使用的 API 服务。

我正在考虑创建一个 api 版本，这样当 web api 发生变化时，iOS 应用程序就会知道。

关注点：

  • Web 应用程序 api 更改时需要更新 iOS 应用程序（除非我保留旧 api 可用..这是一个不错的选择）
  • 如果在未更新 Web 应用程序 api 时更新了 iOS 应用程序，这也会导致问题

我的 iOS 应用程序是否应该指定它需要的 api 版本？

  • 如果 iOS app api 小于 web api: 显示消息: Please update iOS app
  • 如果 iOS 应用 api 大于 web api：显示消息：请更新 web 应用

这是最佳实践吗？

我应该为每个版本创建一个 api 类并扩展以前的版本并在它们更改时覆盖方法吗？

例子

ApiV1 extends CI_Controller
{
   function list_customers(){//Code}
   function saveSale() {//Code}
}

ApiV2 extends ApiV1
{ 
   function saveSale()
   {
      //New way of saving sale
   }
}

另外，如果我对 v1 api 将不再工作的数据库结构进行更改，会发生什么情况？（例如，更改了数据库表的名称？）

4

3 回答 3

9

通常，您希望在服务 API 和客户端之间创建一个相当松散的耦合。作为一项规则，总会有多个版本的客户端总是四处飘荡，您希望尽可能少地强制用户升级。

API 版本的完整版本实际上在 Web 服务中很少见，通常只对应于对数据模型、安全模型等的重大更改。允许多个版本共存可能需要对服务进行一些额外的工作，但值得它允许现有客户继续工作。

为此，请在设计前仔细考虑您用作独立于当前客户端 UI 需求的抽象实体的“模型”。（如果您想针对您的特定情况进行更具体的思考，您可能希望发布一个关于建模您的需求的单独问题。）但是不要太担心提前永远解决所有需求，因为需求将不可避免地发生变化。

完成此操作后，请通过在服务 API 中构建一些版本控制概念来为未来做好准备。需要考虑的一些事项：

  1. 作为 URL 方案的一部分的显式版本或在例如身份验证握手期间最初指定的版本。这是一种干净地命名客户端访问内容的方法。（前者会导致服务上的显式 URL 路由，后者在破解 auth 令牌后需要更多的体操来路由。）
  2. 一个已知的错误响应，表示“此 API 调用已过时”，较早的客户端可以识别该响应并告诉用户他们的客户端需要更新

在服务上，您的设计可以像您注意到的那样明确，使用具有方法覆盖的控制器，但在更高级别：saveSale方法不太可能在版本之间表现得非常不同。似乎更有可能saveSale在 V1 中有一个方法来做基线的事情，然后可能会在 V2 中保存一些额外的数据。发生这种情况时，如果存在额外的数据位，代码可能只是有条件分支。所有这些都是另一种说法，即服务 API 实际上并不会经常发生不兼容的变化。list_customers随着时间的推移，可能会返回更多信息。这并不一定意味着您的 API 需要一个新版本，或者旧客户端不应该忽略任何他们不需要的额外信息。

回复：关于数据库表名的最后一个问题。这些可能会在内部发生变化，但您不需要将它们显式映射到客户看到的内容。API 是一个稳定的接口，理想情况下应该隐藏您不断发展的服务的实现细节。

当作为一个整体，您决定 API 需要做什么的整体情况发生了显着变化，以至于它无法和平地满足现有客户的需求时，您将选择修改 API。当您决定在服务上维护对它们的支持导致您比安装基础更令人头疼（一个非常业务/案例特定的问题）时，您将选择弃用和废弃某些客户端版本。

祝你好运。

于 2013-03-10T19:46:43.923 回答
0

我不知道什么是最佳实践，但是我绝对建议您的 iOS 应用程序跟踪它正在寻找的 API 版本，并专门请求该版本。例如，“/api/v1/....”的 URL。这样当你更新你的 API 时，你可以简单地将它升级到不同的版本（'/api/v2/...'，并让 iOS 应用程序单独使用 v1。显然你应该向 iOS 用户显示一条消息当存在较新版本时进行升级（可能是您响应中的元字段）。

这种方法应该允许您继续开发您的 API，而不会中断无法升级其应用程序的人员。

更新

还有一件事; 如果您进行的更改会使以前的版本无法运行（例如更改表名、架构等），您应该有一个 iOS 应用程序可以理解的状态代码。与消息“此 API 版本已停用”相关的内容。你必须更新'。

当 API 被弃用（即存在新版本）时，我也会推荐类似的标头（或其他东西）。显然继续提供请求的信息/操作，但是警告该版本不再受支持并且应该升级（甚至触发您的应用程序中的某些内容进行升级）可能会有所帮助。

于 2013-01-25T19:05:49.263 回答
0

我不知道让您的 iOS 应用程序指定它所需的 api 版本是否是一种好习惯，但我认为这是一种安全的做法；但是，一个问题是，如果您经常更新您的 api，那么很快就会变得麻烦/烦人，不得不经常更新应用程序。

我会保留旧方法名称并添加具有不同名称的方法，以避免用户在更改 Web api 时必须更新到新版本的应用程序。

我不会为每个版本创建一个 api 类来扩展以前版本的 api。

我想说更改数据库结构将需要更改/更新您的 api，除非您还想保留旧版本的表名或定义或数据，这在大多数情况下是不可行/不实用/不方便的。在这种情况下，您希望您的用户更新到新的应用程序和 API。

看看这个答案，它指向 API 设计原则和实践的介绍。

于 2013-03-11T19:18:50.007 回答