RESTful APIの末尾のスラッシュ

私はRESTful APIの末尾のスラッシュをどうするかについて議論していました。

犬と呼ばれるリソースと、個々の犬用の下位リソースがあるとします。したがって、次のことができます。

GET/PUT/POST/DELETE http://example.com/dogs
GET/PUT/POST/DELETE http://example.com/dogs/{id}

しかし、次の特別な場合はどうしますか：

GET/PUT/POST/DELETE http://example.com/dogs/

私の個人的な見解では、これはid =で個々のdogリソースにリクエストを送信するということnullです。この場合、APIは404を返すはずです。

他の人は、リクエストがdogsリソースにアクセスしている、つまり末尾のスラッシュが無視されると言います。

誰もが決定的な答えを知っていますか？

api rest http

— Gaz_Edge
ソース

RESTfulの方法は、dog / idとdogs（すべての犬を意味する）を区別することだと思いました。

— pdr

本からRESTful Webサービス-従属リソース：他の「親」リソースに関連して存在するリソース、つまりdogs / {id} Web対応データベースは、テーブルをリソースとして公開し、個々のデータベース行をその従属リソースとして公開します。

— Gaz_Edge

dogリソースにアクセスしているため、末尾のスラッシュは無視する必要があります。つまり、削除を適用すべきでないものを削除しようとすると、禁止された応答が返されます。404も許容できると思います。それは重要ですか？

— ベンジャミングリュンバウム

私は従いません-誰があなたが犬を削除できないと言ったのですか？犬を削除すると、それ自体とすべての個々の犬が削除されます。だから、犬への呼び出しを許可することは危険だと思います。クライアントが個々の犬を削除するつもりだったが、誤って{id}を削除した場合はどうなるでしょう。その結果、すべての犬が削除されます。より安全、それは{ID}ヌルを求めていると仮定し、404を返す

— Gaz_Edge

私が治療したいdogsとdogs/同等として。私にとってdogs/は、それが個々の犬を含むディレクトリであることは明らかです。あまり明確でdogsはありませんが、ほとんどのウェブサーバーが末尾のないディレクトリへのアクセスを受け入れるように、私はそれを同等のものとして扱い/ます。

— CodesInChaos

回答:

これは信頼できません（RESTには正確な意味がないため）。しかし、RESTに関する元の論文では、完全な（/で終わらない）URLはリソースに名前を付けますが、スラッシュ '/'で終わるURLはリソースグループです（おそらくそのようには言いません）。

末尾にスラッシュが付いたURLのGETは、使用可能なリソースをリストすることになっています。

GET http://example.com/dogs/          /* List all the dogs resources */

スラッシュを含むURLのPUTは、すべてのリソースを置き換えることになっています。

PUT http://example.com/dogs/          /* Replace all the dogs resources */

スラッシュを含むURLのDELETEは、すべてのリソースを削除することになっています

DELETE http://example.com/dogs/       /* Deletes all the dogs resources */

スラッシュを含むURLのPOSTは、新しいリソースを作成し、その後アクセスできるようにすることになっています。適合させるには、新しいリソースをこのディレクトリに配置する必要があります（ただし、RESTfulアーキテクチャの多くはここでごまかしています）。

POST http://example.com/dogs/        /* Creates a new dogs resource (notice singular) */

等

この件に関するwikiページは、それをうまく説明しているようです：

https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_Web_servicesの例を参照してください。

— マーティン・ヨーク
ソース

また、ディレクトリは、多くの場合、末尾に書かれている通常のパス/ URLモデル、フィット/

— CodesInChaos

では、末尾なしでリソースグループにアクセスするとどうなります/か？

— 13

@oberlies：コンテキストに依存します。ベストプラクティスのみの厳格なルールはありません。ルールには常に例外があり、それはあなたがそれが意味することを期待するものを意味するはずです。上記の例でGET http://example.com/dogsは、犬に関するメタ情報を返します（リスト自体ではなく、犬のリストに関するメタ情報）。たぶん、または多分そのエラー。

— マーティンヨーク

As the last character within a URI’s path, a forward slash (/) adds no semantic value and may cause confusion. It’s better to drop them completely.

これは、トレーニングスラッシュを使用しないことを提案する唯一の場所ではありません

— -Laiv

@Laiv私は感情に同意しません。しかし、より信頼できるリファレンスをリンクしてください（それは弱いリンクです）。

— マーティンヨーク

Does anyone know the definitive answer?

サービスがRESTfulと見なされるために必要なものに関する公式文書がないため、1つはありません。

それは、使いやすさのためだけに末尾のスラッシュを許可するということです。技術的に言えば、これはnull IDを持つ犬にアクセスしようとしていると見なすことができます。ドキュメントで読んでいない限り、ユーザーがこのジャンプを行うことはありません。APIに対してコードを記述しようとしているユーザーが、単に習慣から末尾のスラッシュを含めて、犬のリストが必要なときになぜ404応答を受け取るのか疑問に思っています。

— マイク
ソース

DELETE example.com/dogsについてはどうですか？

— ベンジャミングリュンバウム

犬はすべての個々の犬の親であるため、犬を削除すると、すべての個々の犬とそれ自体が削除されます。あなたがそれをしない場合は、お使いのハイパーメディアが打破されます

— Gaz_Edge

@Gaz_Edge：REST example.com/dogsでは、リソースとは完全に独立したリソースexample.com/dogs/Xです。したがって、DELETEでexample.com/dogsすべてのdogs / *を削除する必要はありません（ただし、それがセマンティクスであれば可能です）。ただし、DELETE example.com/dogs/はすべてのdogs / *を削除する必要があります。

— マーティンヨーク

/ dogsまたは/ dogs /を削除したときに何が起こるかは、APIのコンシューマーが期待するものに基づいているため、RESTfulの決定的なルールセットがないため、もう一度言います。彼らは実際に単一のリクエストですべての犬を削除したいと思うでしょうか？そうであれば、そのように実装し、そうでなければ、405 Method Not Allowedレスポンスを返します。

— マイク

私はこれが古いスレッドであることを知っていますが、最近このことについて疑問に思っています。何が価値があるため、OS XのBashシェル扱いfoo、foo/とfoo////全く同じ。基本的に、空のパスセグメントを削除するようです。だから、あなたはあなたのRESTサービスと同じアプローチに従う、場合dogsとdogs/同じものを指します。

— グレッグブラウン

二つの方法。

方法1

子を含む可能性のあるリソースには、常に末尾のスラッシュを使用してください。

ファイルがあるpublic_htmlディレクトリで「GET」を検討してください。

hello.htmlがファイルの場合は不可能です。

/hello.html
/hello.html/youagain.html

ただし、hello.htmlがディレクトリの場合は可能です。

/hello.html/     (actually /hello.html/index.html)
/hello.html/youagain.html

したがって、「hello.html」が子を持つことができる場合、「/ hello.html /」および「/hello.html/index.html」（または単に/hello.html/）はこれらの子のリストです。。

方法2

賢明であれ"。

$ find
.
./hello.html
./hello.html/index.html

findコマンドはhello.htmlのタイプを気にしません。気にするディレクトリまたはファイルは、オブジェクトの名前です。「cp youagain.html hello.html」と書くと、cpはhello.htmlの処理方法を理解できます。cpはスマートです。あなたのウェブサーバーもスマートです。パス処理ライブラリがあります。ルーティングがあります。名前がオブジェクトであるか、ディレクトリであるかを統計して通知できます。それは何とか何とかをリダイレクトするか、あるいは両方に対して同じ応答を提供することさえできます。これはすごい!!! 仕方。たくさんの技術。すべてを実行できるのに、パス文字列を単純に連結したい人は誰だろうか？

— サミュエル・ダニエルソン
ソース