これらはよくあることではない。仕様には多くのサンプルを含めるべきである。Effectsこれまでに述べたように、ステータスコードはレスポンスの具体的な作用を明らかにする。リソースが移動したことをクライアントに伝えており、必要に応じて新しいリクエストで作ることができる。仕組みを使うきっかけになる。リクエスト数の上限であるため、落ち着くまでリクエストを止めることをクライアントに伝えている。あっても固有の処理がある。クローラーのような自動的なエージェントは、リソースがすでに存在しないことを示すシグナルとしてそれを使用する。これらの具体的な作用は、上記で述べた汎用的なセマンティクスに一致する。ソフトウェアによって処理されるためである。スパイダーによるものである。リソースのさまざな状態に関する情報が担うことは(「ここにある」「ここにはない」「向こうにある」とか)、それらが受け取るものとほぼ同じくらいアプリケーション固有のことである。ステータスコードを使うか検討する際に考慮するべきことであり、アプリケーション固有のセマンティクスにどのようにマッピングするかということではない。レスポンスの意図された処理が既存のステータスコードと同じ場合は、それを使うこと。レイヤーで自動的に処理されない。使うのであれば、それをドキュメントに記載した方がよい。定義されているため、ステータスコードのセマンティクスを再定義する必要はない。ステータスコードに「深く」マッピングしようとすることは間違いであり、ほとんどの場合において、その粒度ははるかに粗い。含めるのが適切である。ほとんどの場合において、使われるステータスコードを指定する必要はなく、「成功レスポンス」ということだけでおそらく十分である。ヘッダーを作成することもできるが、ここでは言及しない。拡張機能を構築している場合である。その場合、ステータスコードの仕様に記載されていることや、使おうとしている既存のヘッダーに留意する。これらは互換性を保つ必要がある。仕様を更新しない限りこれは機能しない。実装に明らかな効果がある。既存のステータスコードで同様な効果があるものはない。試してみたので備忘録。