データを送信して、APIサーバーに存在するかどうかを比較する必要があります。例えば：
$a['foo'] = 'hello';
$a['bar'] = 'world';
$rest->verb('resource', $a);
の値がAPIサーバーに存在する場合は、elseを返す必要がfooあります。barOKBad Request
GETより適切に聞こえ、クエリ文字列でデータを送信するだけなので、動詞として使用したいと思いますが、機密情報であり、post / putを介してはるかに安全に送信される場合はどうfooなりますか？barしかし、私は何も追加または更新していません。
この状況で最高の動詞は何ですか？
さて、セキュリティ上の懸念からGET 1を除外すると、事実上POST / PUTのみが残ります（DELETEを無視してフラットになります）。
これらの利用可能なオプションのうち、POSTを使用することをお勧めします。これは、POSTがより一般的であり（特にRESTの外部）、全体的にHTTP動詞の特定性が低いためです。
POST動詞には、さまざまな意味があります。これは、HTTP動詞のスイスアーミーナイフです。 一部のリソースでは、内部状態を変更するために使用される場合があります。他の人にとっては、その振る舞いはリモートプロシージャコールの振る舞いかもしれません。
1 GETの問題は、サーバーへのデータをURI（リソース名とクエリ文字列）を介して転送する必要があることです。したがって、この応答は、POST動詞を使用する要求が、機密情報を転送するためにURIを使用しない、またはGETよりも優れているとは想定していません。記事HTTPSを介したクエリ文字列はどの程度安全ですか？HTTPS接続（すべての機密要求に使用する必要があります）を使用する場合でも、URIのデータに関するいくつかの懸念事項について説明します。
そのような質問をサーバーに送信して、OKを取り戻す場合。1ミリ秒後、それはもうOKではないかもしれません。したがって、サーバーからの古い（ミリ秒古いがまだ古い）応答を真実として使用してクライアント入力を受け入れる場合でも、後でそのデータを保存しようとするとうまくいかない可能性があります。
サーバー上に何かを作成してみてください。つまり、PUTまたはPOSTである必要があります。RESTについて読むと、結果のリソースのURLがわかっている場合はPUTを使用し、それ以外の場合はPOSTを使用する必要があると記載されています。そこにあります。すべてが機能する場合は201を送信し、そうでない場合は409を送信することをお勧めします。
PUT / POSTを使用してサーバー上に作成するものは、最終データである必要はありません。クライアントがこのIDなどを要求したことを示すトークンである可能性があります。
さて、サーバーに何かを保存する前に追加の事前チェックが必要な場合は、ExpectまたはAcceptなどを確認することをお勧めします...よく覚えていないでください。これがRESTを使用するときの2人の友人です。:)
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
http://en.wikipedia.org/wiki/List_of_HTTP_header_fields
また、RESTに関するこの非常に優れた本をお勧めします：http ：//shop.oreilly.com/product/9780596529260.do