はじめに
タイトルについて記事にしました。
この記事で得る内容は以下の通りです。
・ クールなURIの設計・変更・テクニック・不透明さについて
■ Web API入門についての過去記事
・ Web API入門#1 〜APIとWeb API、Webの概要〜
・ Web API入門#2 〜REST、アーキテクチャについて〜
・ Web API入門#3 〜URIの基礎知識〜
クールURIとは何か
クールURI
良いURIやきれいなURIのことを「クールURI」（Cool URI）と呼びます。
この起源は、Webの発明者Tim Berners-Leeが1998年に発表した「Cool URIs don’t change」
（クールなURIは変わらない）というWebページです。
クールなURIの設計方法
プログラミング言語に依存した設計を含めない
ファイル拡張子が含まれたURI（https://〜.com/posts.php）のような構成で、そのWebページを
phpではなく、他の言語で作り直そうとリニューアルをする時に、URIの構造のまま変えることができません。
また、プログラミング言語を変更すると、そのURIにアクセスすることができなくなります。
また、開発用ディレクトリや大文字をURIに含めません。
メソッド名やセッションIDを含めない
例えば、/posts?action=hogeのように、実行したいアクションをURIに含めず、HTTP用のメソッドを使います。
また、ログインする度に、セッションIDが変わってしまうので、URIが常に変わってしまいます。
基本的に、セッションIDは、Cookieであったり、JWT（JSON Web Token）に保存するのが主流のようです。
URIにはリソースを指し示す名詞を使う
基本的に、URIには名詞を使い、動詞は使いません。（HTTPメソッドで表現することができます)
なるべくシンプルかつ人間が読んで理解できる
良い例はこちらで、15回目の投稿記事だとひと目で見て分かりやすいと思います。
https://hoge.com/posts/15
悪い例はこちらで、基本的に冗長で、dogは犬なのか、カテゴリーで書いているのか設計者しか分かりません。
また、articleも、postsがあるのであれば、書く必要性はあまり感じられません。
カテゴリーはURIに含めず、クエリパラメータに指定する方が良いと思います。
https://hoge.com/dog/posts/foods/article/12
URIの変更方法
URIの変更方法ですが、URIを普通に変えてしまうと、リンク切れを起こしてしまい、URIが指し示すリンクにアクセスができなくなってしまいます。その状態を避ける為に、301リダイレクトというものを使います。
301リダイレクト
URIの状態変更を知らせるもので、恒久的なURIの変更を意味します。
Webページの移転などで使い、旧Webページにアクセスをすると、新しいWebページにリダイレクトされます。
また、ユーザーフレンドリーだけでなく、SEOにも効果があります。
SEO的には、元々運営していたサイトのページランク（検索結果で上位に表示されやすくなる）も継承します。
302リダイレクト
302リダイレクトというものもあり、こちらは一時的なURIの変更を意味します。
URI設計のテクニック
URIにバージョン番号を含める
URIにバージョンを含めてあると、APIの更新時に、URIの大元は変えずにAPIのバージョンをv2からv3に変更するだけで使えるようになります。
| API | URI |
|---|---|
| Google Calendar | http://googleapis.com/calendar/v3/ |
| http://apis.twitter/1.1/ | |
| Youtube | http://googleapis.com/youtube/v3 |
拡張子を用いて多言語対応のリソースを切り替える
拡張子については、プログラミング言語に依存した設計を含めないの項目でお伝えしましたが、今回はプログラムのファイル拡張子ではなく、言語を示す拡張子を使うことによって、多言語対応することができます。
例①：http://hoge.com/jpにアクセスすることにより、日本語に対応したページに移動します。
例②：英語対応：http://hoge.com/enにアクセスすることにより、英語に対応したページに移動します。
URIの不透明性を保つ
URIからリソースの構造を推測されないようにするべき
APIを経由せずにリソースにアクセスされてしまうと情報が漏えいしてしまいます。
対策は、API以外のアクセス経由を遮断するなど色々ありますが、URIを推測されないように不透明さを保つ必要があります。
URIに拡張子を含めるとその言語で操作されてしまう可能性がある
URIに拡張子が含まれていると、何を使ってサイトを構成しているのかが分かるので、スクリプトを埋め込まれたりされやすくなります。
これらのことから、API経由以外でサーバーから情報が抜き出される可能性がありますので、クライアント側でURIを構築しないなどの対策を講じることが必要です。