4

我目前正在开发一个 Restful API,我想知道最优雅、最长寿的解决方案是什么。

一些数据:

  • Rest API:服务器后端
  • 应用:移动应用(ios、android等)

两者都由我们管理和消费。

这是我的要求:

  1. 更新是可选的,但推荐,我们只是想通知客户端更新他的应用程序。

  2. 需要更新并且 API 不再可用(由于 api 版本控制,这永远不会发生,但谁知道)

我可以想到几个解决方案:

  • 包括一个新的 HTTP 标头,例如:

X-Client-Update: text="Some informative and meaningful message"; button="Do upgrade now!"; uri="itms-apps://itunes.com/apps/DevelopmentCompanyLLC"

应用程序将负责处理它并将其显示给用户。

  • 提供端点:

要求:

POST /api/versions/
Content-Type: application/json
{"client_version": "4.3", "os_version": "6.0", "os_vendor": "ios"}

响应(可用更新):

{
    "current_version": "4.4", 
    "latest_compatible_version": "4.0",
    "update_required": false,
    "update_available": true,
    "message": "A new awesome update is available, download it now",
    "uri": "itms-apps://itunes.com/apps/DevelopmentCompanyLLC",
    "button_text": "I want it, and I want it now!"
}

响应(无可用更新):

{
    "current_version": "4.3", 
    "latest_compatible_version": "4.0",
    "update_required": false,
    "update_available": false,
}

如果需要更新应用程序,我还希望始终返回将由应用程序处理的错误。

我想知道我应该使用哪种 HTTP 状态,现在我想到了,400 Bad parameters因为我找不到更好的代码。

相应的消息将与端点解决方案提供的消息非常相似。

4

1 回答 1

1

由于服务器和客户端都是由您开发的,因此使用哪个状态码(恕我直言)并不重要。除了400您的选择之外,您还可以查看以下状态代码:

  • 403Forbidden - 如果服务器理解请求但拒绝执行它,则适用;服务器应在实体中描述拒绝的原因。
  • 501未实现 - 如果服务器不支持 [不再] 满足请求所需的功能,则适用。

正如您所写的,必需的更新永远不会正常发生,因此可选更新是主要用例,后者的条件响应似乎适合任何成功的请求。在这种情况下,您可能应该200像往常一样使用状态代码,并依赖响应中的附加标头。

于 2012-10-24T11:01:16.073 回答