iOS消费API设计 [英] iOS consuming API design

问题描述

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

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

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

关注点：

• 当web应用程序api发生变化时，需要更新iOS应用程序（除非我保留遗留api ...这是一个不错的选择）


• 如果在未更新web app api时更新iOS应用程序，这也会导致问题

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

• 如果iOS app api小于web api：显示消息：请更新iOS应用程序


• 如果iOS app api大于web api：显示消息：请更新网络应用

这是最佳做法吗？

我应该为每个版本制作api类并扩展以前的版本并在更改时覆盖方法吗？

示例

  ApiV1扩展CI_Controller 
 {
 function list_customers（）{// Code} 
函数saveSale（）{//代码} 
} 
 
 ApiV2扩展ApiV1 
 {
函数saveSale（）
 {
 //保存销售的新方式
} 
} 
  

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

解决方案

一般情况下，您希望在您之间创建一个相当松散的耦合服务API和您的客户端。通常情况下，会有多个版本的客户端总是浮出水面，并且您希望尽可能少地强制升级用户。

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

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

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

1. 作为URL方案的一部分的显式版本或最初在例如期间指定的版本。认证握手。这是一种干净地命名客户端访问内容的方法。 （前者会导致服务上的显式URL路由，后者在破解身份验证令牌后需要更多体操路由。）


2. 已知错误响应，表示此API调用是过时的，早期客户可以识别告诉用户他们的客户需要更新

在服务上，您的设计可以是正如您所指出的那样，使用带有方法覆盖的控制器，但处于更高的级别： saveSale 方法在某些版本之间的行为方式可能不同。似乎更有可能在V1中有一个 saveSale 方法执行基线操作，然后可能是在V2中保存一些额外的数据。当发生这种情况时，如果存在额外的数据，代码可能只有条件分支。所有这些都是另一种说法，即服务API实际上并不会经常变得不相容。 list_customers 可能会随着时间的推移返回更多信息。这并不一定意味着您的API需要新版本，或者旧客户端不应该忽略他们不需要的任何额外信息。

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

作为一个整体，当你决定API需要做的整体情况发生了重大改变以至于不能和平时，你会选择修改API满足现有客户的需求。当您决定在服务上维护对它们的支持导致您比安装基础值得更加头痛时（特定于业务/案例的特定问题），您将选择弃用和废弃某些客户端版本。

祝你好运。

I am going to develop an iOS app for a web application. (The web app uses code igniter)

I am going to create an API Service that the iOS app will consume.

I am thinking of creating an api version, so when the web api changes, the iOS app will know.

Concerns:

• iOS app will need to be updated when web application api changes (unless I keep legacy api available..Is this a good option)
• If iOS app is updated when web app api is NOT updated this will cause a problem too

Should my iOS app specify the version of the api it requires?

• If iOS app api is less than web api: Display Message: Please update iOS app
• If iOS app api is greater than web api: Display Message: Please update web app

Is this best practice?

Should I make an api class for every version and extend the previous version and override methods when they change?

Example

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

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

Also what happens if I make a change to the database structure where the v1 api will no longer work? (Example, changed the name of a database table?)

解决方案

In general, you want to create a fairly loose coupling between your service API and your client. As a rule, there will be multiple versions of the client always floating around in the wild, and you want to force upgrades on users as rarely as possible.

A full rev of an API version is actually somewhat rare in web services, and usually only corresponds to significant changes to the data model, security model, etc. Allowing multiple versions to coexist may require some extra work on the service, but can be worth it to allow existing clients to keep working.

To that end, think carefully in the design up front about the "model" you're using as an abstract entity independent of the current client UI needs. (If you want more specific thinking around your particular case, you may wish to post a separate question about modeling your needs.) But don't worry too much about solving all of the needs forever in advance, because requirements will inevitably change.

Once you've done this, do prepare for the future by building some notion of versioning into the service API. Some things to consider:

1. An explicit version as part of the URL scheme or specified initially during e.g. auth handshake. This is a way to cleanly namespacing what the client accesses. (The former would result in explicit URL routing on the service, the latter would require more gymnastics to route after cracking an auth token.)
2. A known error response that means "this API call is obsolete", which an earlier client can recognize to tell the user that their client requires an update

On the service, your design can be as explicit as you note, with a controller with method overrides, but at a little higher level: the saveSale method is somewhat unlikely to behave very differently between versions. It would seem more likely to have a saveSale method in V1 that does the baseline thing, and then maybe e.g. saves some extra bit of data in V2. When that happens, the code might just have conditional branching if that extra bit of data is present. All of this is another way of saying that a service API doesn't actually change incompatibly that often. list_customers could return more information over time. That doesn't necessarily mean that your API needs a new version or that old clients shouldn't just ignore any extra information they don't need.

Re: your final question about database table names. Those may change internally, but you aren't required to map those explicitly to what the client sees. An API is a stable interface that should ideally hide the implementation details of your ever-evolving service.

You'll choose to rev the API when, as a whole, you decide that the overall picture of what the API needs to do is significantly changed enough that it cannot peacefully serve the needs of existing clients. You'll choose to deprecate and obsolete certain client versions when you decide that maintaining support for them on the service is causing you more headache than the install base is worth (a very business/case specific issue).

Good luck.

这篇关于iOS消费API设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！