2017-01-17 9 views
1

私は、リストからタスクに基づいて戦闘を開始できるゲームを作っています。条件付きで利用可能なリソースのRESTコード

あなたが戦闘を完了したら(戦闘に勝利した場合)、進行中の戦闘がないため、戦闘状態は利用できなくなります。

これはGET /バトル時にAPIに反映されます。

  • 進行中のバトルがある場合は、バトルの現在の状態と200個のRESTコードを反映するオブジェクト応答を取得します。
  • がない場合は、の戦闘が進行中であることがわかります。

私の質問は次のとおりです。戦闘が現在利用できないことを表現するためにどのようなRESTコードを使用する必要がありますか?

追加:私の解釈が存在しないページですので、私は404を選んだいない

  • 、おそらく存在しなかった、むしろその可能性がありますリソースよりも、存在したことがないかもしれません存在しますが、今はありません。私は私の解釈について間違っていることを覚悟しています。
  • 私の非常に基本的な研究は、409が適切な指標である可能性があることを示していますが、これは要求(PUTなど)のために競合が発生することを意味します。状態。
  • 200レスポンスで戦闘が起こっていないことだけを詳述することができますが、これはRESTコードジョブのように感じます。
  • 私はRESTコードがこれを見る正しい方法ではないかもしれないことを認識しています。もしそうなら、洞察力を提供してください。また、私が読むべきだと思うものは何でも。私はプロフェッショナルなフロントエンドの開発者ですから、APIを書くのではなく、通常は消費しています。

答えて

1

結果を示す一意の応答コードを使用するという制約の下で、私はHTTP 204(No Content)を選択します。私の理論的根拠は、あなたがしようとしているのは、資源(あなたの戦闘)は有効だが、現時点では利用可能なデータはないということです。

また、バトルが進行中でもなくても、現在の状態を示すペイロードをHTTP 200(OK)に戻すこともできます。これは、呼び出し元のAPIの形状を正規化するのに役立ちますので、私が個人的に行っていることです。呼び出し側は戻りコードの周りにルールを記憶する必要はなく、両方のシナリオで同じデータ構造を受け取り、コンテキストを識別するためにそれを解釈します。これにより、バトルが完了した後、APIに変更を加えずに、バトル・ステータスなどの履歴データを使用してAPIを拡張することもできます。

私が進行中のため、以下のようなものを考えている:

{ 
    "Id"   : 1234, 
    "InProgress" : true, 
    "Battle  : 
    { 
     "SomeProp" : "SomeValue", 
     "OtherProp" : "OtherValue" 
    } 
} 

...と進行中の一つではないため、次のようなもの:私は両方信じて

{ 
    "Id"   : 1234, 
    "InProgress" : false, 
    "Battle  : null 
} 

アプローチは適切なRESTfulな応答と見なされます。私には、あなたが提供したいAPI契約の個人的な好みが選ばれます。

関連する問題