RESTの「検出可能な」部分は、通常、以前は存在していなかったサーバーから返された新しいリソース(URIで表される)を指します。クライアントアプリケーションは、自由にそれらのリソースと対話することを選択できます。
たとえば、私のアプリケーションは、ローカルライブラリにあるものの表現を返すURIである可能性がGET
あります。/library
返されるデータ(特定のJSONベースのメディアタイプとしてエンコードされている)は、次のようになります。
{
"printedBooks" : "/library/books",
"audioTapes" : "/library/tapes"
}
ここで、数か月後にGET
同じURIで同じことを行ったとすると、次のペイロードが返される可能性があります。
{
"printedBooks" : "/library/books",
"audioTapes" : "/library/tapes",
"magazines" : "/library/magazines"
}
magazines
今、私がおそらくGET
どんな種類の雑誌が利用可能であるかを知ることができるリソースへの新しいリンクがあります。クライアントアプリケーションがそれを気にしない場合でも、大したことはありません。以前と同じように、他の2つのリソースを使い続けるだけです。将来のある時点で、雑誌検索のサポートもコーディングする可能性があります。
しかし、この新しいリソースの存在に自動的に適応できる、ある種の超動的なファンシーシュマンシークライアントアプリケーションを作成した場合、アプリケーションのユーザーは何の努力もせずにそれを使用できるようになります。アップグレードは必要ありませんでした。サーバーは新しい機能を提供し、クライアントはそれを最大限に活用しました。Webブラウザはこのように機能します(人間が「ダイナミズム」の大部分を駆動している場合でも)。
パラメータに関する特定の質問に対して:これらは通常、サーバーのAPIドキュメントの一部として指定されています。クライアントが100%汎用的で適応性があることを可能にする自動化された方法でパラメーター構文を指定するAPIを知りません。
明確に定義されたRESTfulAPIは、それが使用するすでに指定されたテクノロジー(HTTP、URI、コンテンツタイプネゴシエーション、ヘッダーなど)の肩に乗っており、それらを再定義するのではなく活用します。GET
そのため、おそらく/library/magazines
URIでを実行し、JSONベースのエンコーディングを要求できることを知っています。そして、成功する可能性が非常に高いです。特定の雑誌へのURIがある場合(たとえば/library/magazines/1234
)、それを呼び出すことで削除を試みることができDELETE
、返されたHTTPステータスコードに基づいて成功したかどうかがわかります。これらはHTTPですでに指定されているアクションであるため、これらのことを行うためにドキュメントを読んだり、コーディングの魔法を使用したりする必要はありませんでした。
ただし、POSTで新しいマガジンを作成するに/library/magazines
は、URI内で渡すか、POSTの本文内でパラメーターを渡すかに関係なく、パラメーターデータの表現がどのようになるかを知る必要があります。これは、APIドキュメントで帯域外で指定する必要があるデータです。
つまり、要約すると、RESTfulサーバーは、以前は見たことのない新しい情報をクライアントに送り返すことができます。これが、RESTでの発見可能性の核心です。ただし、クライアントがサーバーにデータを送信する場合は、サーバーが理解して受け入れるデータを送信する必要があります。これについては、通常、ドキュメントで説明されています。