サーバーが Web サービスを RESTful として分類するために許可する HTTP 動詞の最小セットは何ですか?
ホスティング会社がPUTとDELETEを許可していない場合はどうなりますか?
これは実際に重要ですか? GETとPOSTだけで幸せに暮らせるでしょうか?
更新:回答ありがとうございます。Bill Venners と Elliotte Rusty Harold のインタビューへのリンクがあるため、Roger の回答がおそらく最良でした。今わかりました。
サーバーが Web サービスを RESTful として分類するために許可する HTTP 動詞の最小セットは何ですか?
ホスティング会社がPUTとDELETEを許可していない場合はどうなりますか?
これは実際に重要ですか? GETとPOSTだけで幸せに暮らせるでしょうか?
更新:回答ありがとうございます。Bill Venners と Elliotte Rusty Harold のインタビューへのリンクがあるため、Roger の回答がおそらく最良でした。今わかりました。
はい、PUT と DELETE なしで生活できます。
この記事では、その理由を説明しています: http://www.artima.com/lejava/articles/why_put_and_delete.html
真の RESTafrians にとって、これは異端かもしれませんが、現実の世界では、自分が持っているものでできることを行います。できる限り合理的であり、独自の慣習にできる限り一貫性を持たせてください。ただし、P と D がなくても優れた RESTful システムを確実に構築できます。
rp
X-Http-Verb-Override:DELETE inst を使用することもできます。HTTP DELETE の。これは、HTTP動詞を変更できず、GETとPOSTのみをサポートするSilverlightクライアントにも役立ちます...
プロトコルの実装が壊れている場合、REST ではプロトコルの規則を破ることができます (そのため、非標準的なことは、実装の壊れた部分を回避することだけです)。そのため、REST 内では、他のメソッドを使用して、DELETE や PUT などの一般的にサポートされていない動詞を表すことができます。
編集: 以下は、REST を作成および定義した Fielding からの引用です。
REST API には、HTTP の PATCH メソッドやリンク ヘッダー フィールドなど、標準プロトコルの指定されていないビットの詳細を記入または修正することを除いて、通信プロトコルへの変更を含めることはできません。壊れた実装 (HTML が HTTP のメソッド セットを定義していると信じるほど愚かなブラウザーなど) の回避策は、個別に、または少なくとも付録で定義する必要があります。[ここでの失敗は、リソース インターフェイスが汎用ではなくオブジェクト固有であることを意味します。]
GET と POST のみを使用する場合でも、RESTful です。Web サービスは、GET または POST のみを必要とする処理のみを実行する場合があるため、問題ありません。
今日の Web ブラウザーは、GETS + POSTS のみを処理します。たとえば、Rails では、PUTS + DELETES は非表示のフォーム フィールドを介して「偽造」されます。
フレームワークに PUTS + DELETES を「サポート」する回避策がない限り、今のところ心配する必要はありません。