REST APIでクライアントが十分に高度なものではないのに、それを利用することができない場合に、「発見可能性」の必要性は何ですか？

Question

私が見たさまざまな講演とスキャンしたチュートリアルRESTは、「発見可能性」と呼ばれるものを強調しているようです。私の理解では、この用語は、クライアントがhttp://URL-そして、それができることのリストを自動的に取得します。

私が理解できないのは、「ソフトウェアクライアント」は人間ではないということです。それらは、提供されたリンクを使用して正確に何をすべきかを理解する直感的な知識を持たない単なるプログラムです。人だけがWebサイトにアクセスして、表示されたテキストとリンクを理解し、それに基づいて行動できます。

では、クライアントの開発者が提示されたリソースで実際に実験しない限り、そのような検出可能なURLにアクセスするクライアントコードが実際には何もできない場合、発見可能性のポイントは何ですか？これは、ドキュメンテーションマニュアルで利用可能な関数のセットを定義するのとまったく同じように見えます。異なる方向からであり、実際には開発者の作業が増えます。実際のRESTリソースの外部にあるドキュメントで実行できることを事前定義するこの2番目のアプローチは、劣ると見なされるのはなぜですか？

Marjan Venema · Accepted Answer

発見可能性の必要性は関係ないかもしれませんが、発見可能性を可能にするリンクはより多くの目的に役立ちます。これらの中で最も重要なのは、私の考えでは、クライアントへの応答で完全なURIを提供することは、クライアントがURIを「作成」する必要がないことを意味するということです。つまり、クライアントがURIの構造についての知識を必要とすることはありません。さらに、サーバー開発者は、古いクライアントがURIの構造化の古い方法に依拠していることを考慮する必要がないため、サーバー開発者は適切な場合はいつでもURIスキームを変更できます。

gnasher729 · Answer

少し前に、非常に理解しづらいドキュメントが含まれているAPIを操作できてよかったです。

サーバーから実際の応答を得ることができたら、ドキュメントをサーバーの応答と比較し、それを使用してドキュメントを解読することができました（そうです、それは正しい用語でした）。問題は、仕様に従って正確に正しくないリクエストがサーバーに送信された場合、エラーが発生するだけであり、ドキュメントが読めないため、正しいリクエストを送信する方法を理解することがほぼ不可能でした。また、APIドキュメントにはさまざまなバージョンがあり、互いに同意せず、おそらくAPI自体にも同意しませんでした。それは助けにはならなかった。

サーバーに送信できるコマンドが1つあり、すべての可能なコマンドのリストとそれらを正確に送信する方法を返す場合、それは非常に役立ちます。発見可能性はクライアントだけでなく、ソフトウェア開発者にも役立ちます。

Bryan Oakley · Answer

「クライアント」はそれを利用するのに十分高度ではないかもしれませんが、クライアントのユーザーは可能です。結局のところ、クライアントはWebブラウザのように単純なものにすることができます。 発見可能性とは、人々がAPIを学習して使用できるようにすることです。

たとえば、Jenkins（CIサーバー）にはRESTのようなインターフェースがあります。任意のページに移動し、URLの末尾に「/ api」を付けると、実行できるすべてのことを説明するページが表示されます。 APIの学習は簡単です。たとえば、 http://ci.jruby.org はjrubyのjenkinsサーバーに移動し、 http://ci.jruby.org/api は特定のページのAPI。

Ed Hastings · Answer

注：私はこの問題の専門家ではありませんが、数年前に人々が「REST」について解釈したさまざまなニュアンスを調整しようとする同様のプロセスを経ました。これは、時間。

私の理解では、これはロイフィールディングのアプリケーション状態のエンジンとしてのハイパーメディア別名 "HATEOAS"に由来します。これは、 "セマンティックWeb"のアイデアを実現するものになります。

基本的に、そして私が理解しているように、RESTfulアプリケーションは基本的に自己記述型であるため、コンシューマーはコンテンツ/機能を使用するために正式な契約について事前の知識を持っている必要はありません。デフォルトのルートエンドポイントからエンゲージし、コンシューマが操作するときにアプリが提供するコンテキスト関連リンクをたどることができます。当然のことながら、消費者は人または全身性物質であり得る。

既知の契約に従ってコンシューマが事前に知っておく必要があるCRUD操作にマップされたプリティURLに「REST」を使用しているだけの場合、ロイフィールディングはそれを本当にRESTfulとは見なしません。

RESTフレーバーRPCサービスの設定が役に立たない/より精巧なRPCモデルを改善し、制限された/制御された使用に適しているとは言えませんが、強硬派はそれに鼻を傾け、それは退化した/実際にはRESTではないと考えます。