1

アプリを開発するとき、サーバーと iPhone は進化し、常に後方互換性があるとは限りません。すべてのリクエストにプロトコル バージョン番号を追加することでうまくいくはずです (代わりに、プロトコル バージョン用の別の Web サービスとしましょう)。Amazon はすべてのリクエストでそれを行います (ここにサンプルがあります): https://forums.aws.amazon.com/message.jspa?messageID=269876 したがって、アプリが現在のプロトコルに対して古すぎる場合、メッセージをブロックするメッセージが表示されます。アプリを開き、ユーザーに更新を求めます。そうしないと、古いアプリを使用している顧客には、うまく機能しないアプリが表示されます。それは良いことではありません。

私の質問は、パーサー、オブジェクト マッピング、およびエンティティ マッピングに干渉することなく、同様のバージョン管理スキーマを JSON 応答に実装するにはどうすればよいですか? なにか提案を？

おそらく、すべてのリクエストのヘッダーでアプリのバージョンを渡すような別のスキーマがあり、エラーの場合、サーバーは次のようなエラー メッセージを返します (Twitter から): {"errors":[{"message":"Sorry, that page does not存在する"、"コード":34}]}

この問題をどのように解決するのか知りたいです。よろしく。

4

1 に答える 1

0

media-type を使用して API をバージョン管理できます。たとえば、メディア タイプがapplication/vnd.ricardo+jsonで、後方互換性のない変更を行う必要がある場合は、application/vnd.ricardo-v2+jsonメディア タイプを作成します。

アプリの新しいバージョンはAccept、application/vnd.ricardo-v2+jsonメディア タイプになり、新しいコンテンツを取得します。アプリの古いバージョンは引き続き使用されAccept、application/vnd.ricardo+json互換性のない変更が表示されることはありません。

古いバージョンのアプリを廃止したい場合は、単にapplication/vnd.ricardo+jsonreturnのみを受け入れるリクエストを作成して406 Not Acceptableください。これをアプリで使用してロジックをトリガーし、ユーザーにアップグレードを促すことができます。

(何らかの理由で) アプリがサーバーの複数のバージョンをサポートできるようにする必要がある場合は、それを使用できますAccept application/vnd.ricardo-v2+json, application/vnd.ricardo+json; q=0.5。この状況では、サーバーはapplication/vnd.ricardo-v2+json可能な場合はコンテンツで応答し、application/vnd.ricardo+jsonそうでない場合は応答します。

これを使用して、新機能の「リリース」をより細かく制御できます。たとえば、アプリのリリースと更新、リクエスト統計を使用して、十分な数のユーザーがいつアップグレードされたかを判断できます。次に、サーバーで機能トグルを切り替え、同時にマーケティング活動を行うことで、新機能のリリースを調整できます。

于 2013-02-04T21:41:18.417 に答える