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

サーバーとクライアントの両方が開発されているため、どのステータス コードを使用するかはそれほど重要ではありません (imho)。どちらを選択したかに加えて400、次のステータス コードも確認できます。

  • 403Forbidden -サーバーがリクエストを理解したが、それを実行することを拒否している場合に適しています。サーバーは、エンティティで拒否の理由を説明する必要があります。
  • 501実装されていません -サーバーがリクエストを満たすために必要な機能を [もう] サポートしていない場合に適しています。

あなたが書いたように、必要な更新は通常は発生しないため、オプションの更新が主なユースケースであるため、後者の条件付き応答は、成功した要求に一見適合します。この場合200、通常どおりステータス コードを使用し、応答の追加ヘッダーに依存する必要があります。

于 2012-10-24T11:01:16.073 に答える