4

コレクションが/items/あり、クライアントがこのコレクションに新しいアイテムを追加できるようにしたいとします。Railsに触発されて、私は次のようになりました。リソースを追加するだけ/items/newで、アイテムを追加したい人が最初に発行GET /items/newし、空のエンティティ（おそらくいくつかのデフォルト値が設定されている）を受け取り、次に目的のフィールドと問題を入力しますPOST /items/。

  • このアプローチは真のRESTAPIに適していますか？何を改善/やり直すことができますか？
  • 突然このアプローチが良い場合（そしてそうでない場合はとにかく）：

    各アイテムに必須フィールドTitleがあるとします。に応答してデフォルト値を返すのはおそらくあまり良くありませんGET /items/new。この場合、何が良いですか？null タイトルを返し、POSTが空のときにエラーを返すには？リソースのコンストラクターのようなロジックを実装するnewには、たとえばクエリ文字列で必須フィールドを要求しますか？他に何かありますか？

ありがとうございました。

UPD。明確にするために、を使用することは、 new「追加」を「割り当て」と「コンテンツの書き込み」に分割することではありません。これは、でデータストアに対するアクションが実行されないためGET /items/newです。これは、エンティティ設計の柔軟性を実現する方法を意味します。リッチクライアントは、新しいものに応じて入力フィールドを動的にレンダリングできます。それは理にかなっていますか？または、契約を修正する必要があり、このような変更のためにAPIをバージョン管理する必要がありますか？

4

2 に答える 2

3

なぜ最初に空のアイテムを返すのですか？代わりに、クライアントに新しいアイテム（そのすべてのプロパティを含む）を/ items/newにPOSTさせます。少なくとも、それがRailsで行われたことを覚えている方法です;）

いずれにせよ、空のアイテムを追加で返すことは役に立たず、追加のネットワークラウンドトリップを追加し、「追加」操作を「コンテンツの割り当て」と「コンテンツの書き込み」に分割することで、RESTアプローチを壊す可能性があります。

一意性チェック、UID生成などを実行する場合は、1回の「完全なアイテムの追加」操作で同様に（またはそれ以上に）実行できます。

更新：混乱は、railsコントローラーがREST APIとしても、WebUIのコントローラーとしても機能するという事実に起因している可能性があります。つまり、一部のアクションはAPI（一部のアプリケーション/コードで使用される）で役立ち、一部のアクションは（人間が使用する）プレゼンテーション層が呼び出すことができるものを必要とするために必要です。「新しい」アクションがAPIで役立つとは思いませんが、ユーザーは空のフォームを取得するために呼び出すことができるものが必要です。

于 2013-03-11T16:42:15.130 に答える
2

通常、REST APIを作成するときは、エンティティ名の単数形を使用するため、

api.company.com/item

そこから、クライアントが特定のアイテムを必要とする場合、HTTPGETを実行します

api.company.com/item/{id}

そして通常、動詞をURLに含めたくありません。そのため、「アイテム/新品」はデザインが貧弱です。標準のHTTPメソッドで十分です（GET、POST、PUT、DELETE）

したがって、あなたの場合は、「item / new」を実行せず、クライアントにHTTPPOSTを実行させることをお勧めします。

api.company.com/item

XMLを実行している場合は、クライアントにXSDを提供して、クライアントが何が必要かどうかを認識できるようにします。JSONを使用している場合は、おそらくどこかに文書化されています。

必須の「タイトル」フィールドの適用に関しては、リソースに投稿されたすべての新しいエンティティの検証を行います。投稿されたデータがマッピングされるドメインモデルがあると仮定します。検証を行ってステータス400のHTTP応答を返すか、APIにカスタムエラー応答がある場合はそれを使用できます。

HTTPステータスコードとその意味を覚えておくためによくチェックするリソースを次に示します。

于 2013-03-11T16:48:30.083 に答える