私が関与している SaaS スタートアップでは、RESTful Web API と、それを使用するさまざまなプラットフォームでのいくつかのクライアント アプリの両方を構築しています。API は理解できたと思いますが、今はクライアントに目を向けています。REST について読んでいると、REST の重要な部分は Discovery であることがわかりますが、Discovery が実際に何を意味するのかについて、2 つの異なる解釈の間で多くの議論があるようです。
開発者の発見: 開発者は、リソース URI、クエリ パラメーター、サポートされている HTTP メソッド、およびドキュメントを参照して API の応答を実験することで発見したその他の詳細など、大量の API の詳細をクライアントにハードコードします。このタイプの発見には、クールなリンケージと API のバージョン管理の問題が必要であり、クライアント コードと API のハード カップリングにつながります。十分に文書化された RPC のコレクションを使用する場合よりもはるかに優れているようには見えません。
ランタイム検出- クライアント アプリ自体は、アウト オブ バンド情報をほとんどまたはまったく使用せずに、必要なものをすべて把握できます (おそらく、API が扱うメディア タイプの知識のみ)。リンクはホットになる可能性があります。しかし、API を非常に効率的にするには、クエリ パラメータのリンク テンプレートを大量に作成する必要があるようです。これにより、帯域外の情報が忍び寄ります。開発でここまで来ました。しかし、私は疎結合のアイデアが好きです。
ランタイム検出は REST の聖杯のようですが、そのようなクライアントを実装する方法についての貴重な議論がほとんど見られません。私が見つけたほぼすべての REST ソースは、開発者の発見を想定しているようです。ランタイム検出リソースを知っている人はいますか? ベストプラクティス？実際のコードを含む例またはライブラリ? 私は 1 つのクライアントの PHP (Zend Framework) で作業しています。もう一方は Objective-C (iOS) です。
開発者コミュニティの現在の一連のツールと知識を考えると、ランタイムの発見は現実的な目標ですか? すべての URI を不透明な方法で処理するようにクライアントを作成することはできますが、これを最も効率的に行う方法は、特に低帯域幅の接続では問題です。とにかく、URI は方程式の一部にすぎません。ランタイム コンテキストでのリンク テンプレートはどうですか? 多くの OPTIONS リクエストを行う以外に、どのメソッドがサポートされているかを伝えるのはどうですか?