web-dev-qa-db-ja.com

REST APIでコロンは大丈夫ですか?

特定のことについて、多くのREST _http://<whatever>/widgets_または_http://<whatever>/widget/123_などのURIを使用したAPIの例が表示されます。ほとんどの場合、フロントスラッシュのみを使用しますが、特定のid _http://<whatever>/widget:123_のようなコロンを使用したい。

私が見つけたものによると here ベストプラクティスについては、特にコロンの使用についてはほとんどありませんでした。それは許容できるようですが、スラッシュの代わりにそれらを使用することにはいくつかの落とし穴があるのでしょうか?

Express.jsはそれらに問題がないようです(コードに関する限り)。
app.get('/widgets::id', function(req, res){ <...> });

更新:this につまずきました。コロンはこの用途に最適です。

4
Brian Chandler

REST APIを終了していくつかのテストを行ったので、これに答えて閉じます。コロンまたはフロントスラッシュのいずれかで問題はありませんでした。 -slash。MichaelTが最良のポイントを提示すると思います。別のライブラリがそれで動作しない可能性があります。それを拡張して、それは恐ろしいと言います。テストソフトウェアは、通常は行われないため、それを期待していない場合もあります。また、覚えていますコロンを処理するために追加のコードが必要だと思っていましたが、それをフロントスラッシュのままにしておけば、ソースをよりシンプルに保つことができます。

言われていることすべて、私はそれが表示されると言います技術的に私が説明した方法でコロンを使用するのは問題ありませんが、それは価値があるよりも問題があるかもしれないとも言いますそれは、それがよく受け入れられている穀物に逆らうように見えるからといって単純な道です。結局、私はフロントスラッシュで行きました...今のところ。 ;)

3
Brian Chandler

ほとんどの場合、最初のスラッシュの後ろにコロンを使用することで機能しますが、使用することはお勧めしません。ご覧のとおり here コロンは予約済みのトークンであり、ドメイン名の直後(スラッシュの前)のポート番号を指定するために使用されています。したがって、それを使用すると、奇妙なエラーが発生する可能性があります。

どちらかに固執することをお勧めします/または?foo=1&bar=2

2
Bas van Stein

元の RFC1738 またはURI仕様の RFC3986 に記載されているURLの仕様に従って、コロン(:)は特定の目的のために予約されています。 URLのパス部分のスラッシュは、階層を示すためにあります。

したがって、パスにコロンが含まれるルートが一致してもアプリケーションは中断しませんが、提案された仕様には従いません。仕様は合意された標準です。あなたのアプリケーションはあなたが望むことなら何でもできます。

1
Hasen