このトピックの「ディメンション」の1つは省略されていますが、それは非常に重要です。「ベストプラクティス」が、REST機能で実装または拡張しているプラットフォームと一致する必要がある場合があります。
実用的な例:
現在、多くのWebアプリケーションがMVC(モデル、ビュー、コントローラー)アーキテクチャーを実装しています。彼らは特定の標準パスが提供されていると想定していますが、それらのWebアプリケーションに「Enable SEO URLs」オプションが付いている場合はさらにそうです。
かなり有名なWebアプリケーションであるOpenCart eコマースショップです。管理者が「SEO URL」を有効にすると、そのURLが次のような非常に標準的なMVC形式であることが期待されます。
http://www.domain.tld/special-offers/list-all?limit=25
どこ
special-offers
URLを処理するMVCコントローラーです(特別オファーページを表示)
list-all
呼び出すコントローラーのアクションまたは関数名です。(*)
limit = 25はオプションであり、ページごとに25項目が表示されることを示します。
(*)list-all
は、わかりやすくするために使用した架空の関数名です。実際には、OpenCartおよびほとんどのMVCフレームワークにはindex
、ユーザーがデフォルトのアクションを実行したいときに呼び出されるデフォルトの暗黙の(通常はURLでは省略されている)関数があります。したがって、実際のURLは次のようになります。
http://www.domain.tld/special-offers?limit=25
非常に標準的なアプリケーションまたは上記と同様のフレームワーク構造により、多くの場合、それに最適化され、URLを書き換えるWebサーバーを取得します(真の「非SEOされたURL」は次のようになりますhttp://www.domain.tld/index.php?route=special-offers/list-all&limit=25
)。
したがって、開発者は、既存のインフラストラクチャを処理し、「ベストプラクティス」を適用することに直面します。システム管理者でない限り、Apache / NGinxの書き換え構成を微調整する方法を正確に知っています(後者は厄介な場合があります!)。オン。
そのため、REST APIは、参照元のWebアプリケーションの標準に準拠していることがよくあります。これは、REST APIとの一貫性と使いやすさ/速度の両方(したがって予算の節約)の両方を実現します。
上記の実用的な例に戻ると、一貫したREST APIは次のようなURLを持つものになります。
http://www.domain.tld/api/special-offers-list?from=15&limit=25
または(非SEO URL)
http://www.domain.tld/index.php?route=api/special-offers-list?from=15&limit=25
「パスが形成された」引数と「クエリが形成された」引数の組み合わせ。