綺麗なURI（ルーティング）を作るときのTIPS
綺麗なURI（ルーティング）を作るときのTIPS
APIを開発する時にエンドポイントのURIを設定しますが、良いURI設計を意識することが大事です。
.......でも良いURI設計とは一体なんぞや！
良いURI設計とは下記のようなものです。
覚えやすく、どんな機能をもつURIなのかが一目でわかる
次に良い設計のURIの特徴を箇条書きしていきます！
良いURIの特徴その1、短くて入力しやすいURI
URIは長ければ良いと言う訳ではありません。
例えば以下のようなURIがあるとします。
悪い例 http://api.example.com/hogehoge/api/hogehoge
このURIは重複箇所が多く無駄が多いです。
1. apiと言う言葉がURIのホストとパスの両方に含まれている 2. hogehogeが2回記載されている。
以下にシンプルにしたURIを記載します。
良い例 http://api.example.com/hogehoe
良いURIの特徴その2、人間が読んでも理解できるURI
悪い例 http://api.example.com/sv/pic
こちらのURIは見ただけでは意味不明です。
理由は以下のようにワードを簡略化しているからです。
開発者はわかりますが、ユーザーにはわかりづらいです。
1. sv = service 2. pic = picture
良い例 http://api.example.com/service/picture
できる限り標準化されたコードで体系的に書く方がベターです。
良いURIの特徴その3、大文字小文字が混在していないURI
悪い例 http://api.example.com/SERVICE/picture
こちらのURIは大文字と小文字が混在しています。
非常にわかりづらいです、現時点でURIは小文字で統一されることを推奨されています。
良い例 http://api.example.com/service/picture
良いURIの特徴その4、サーバー側のアーキテクチャが反映されていないURI
悪い例 http://api.example.com/cgi-bin/get-user/php?user=11111
このコードは開発者が見ると、思いっきりサーバーのアーキテクチャがバレバレです。
1. PHPで書かれている 2.CGIで動作している 3. userのIDは11111
このあたりの情報がバレると脆弱性に繋がってしまいます。
良いURIはサーバー側のアーキテクチャ情報をURIには記載しません。
良いURIの特徴その5、ルールが統一されているURI
悪い例 http://api.example.com/services?id=100 http://api.example.com/service/id/100
この２つのコードには全くの統一感がありません。
理由はルールが統一されていないからです。
このままでは、ユーザーの混乱を巻き起こし、トラブルに発生する恐れありです。
良いURIはルールが統一されており、わかりやすいです。
まとめ
良いURIを作るにも多くの制約があります。この辺の特徴ははAPI開発する際には頭にいれておかないとですね。
