1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

URIの不透明性

Posted at

#はじめに
技術書で学んだことはどんどんアウトプットすることが大事だと感じ始めたので、少しずつ小さい単位でやっていこうと思います。
今日はこちらの書籍について。
Webを支える技術
こちらの本はweb関連の技術を歴史を振り返りながら、理解を深めていける、良い本だというレビューが気になって買ってみました。
特にREST APIに関しての記述が目立ちますね。

中でも今回はURIの設計方法の一つの考え方についてまとめてみたいと思います。
URIをどのように設定して、パスをどう切るかって結構適当な人って多いと思います。自分がそうなので
、これを機に学んでいきたいと思ってます。

#URIの不透明性
URIをどのように設計するかについての考え方の一つに不透明性というものがあるみたい。
「不透明」な「性質」というくらいであるから、不透明であれば不透明であるほど良いということだ。
これが初めに「?」ってなりました。明確ではない方が良いのである。普通逆だろっておもっちゃいますけどねぇ。
ひとまず読んでみると、まずはじめの考え方として、シンプルなURIは可読性が高いため、ユーザがURIの構造を推測しやすくなるということが言える。
例えば

http://examle.jp/2018/05/05/press.ja
http://examle.jp/2018/05/05/press.en

このURIは末尾に文字コードを付けているため、フランス語のURIは言わずもがな想像がつくと思う。

しかし、URIが想像がついたからといって、そこにリソースが存在するとは限らない。
URI=パス+リソース名ではないのです。

なるほど、確かに。

逆に上記の等式が成り立ってしまうと、サーバーの実装が変更になった際にURLまで変更する羽目になる。
最悪、クライアント側が下手にリソースの構造が見えてしまうことによって、想像でリソースの構造を利用したロジックを実装してしまうことにもなりかねない。

確かに、これはクライアントがサーバーサイドの実装に依存することになり、MVC的な観点から見てもありえないと思われる。

クールなURIは変わらない、だそうですので、少しでもURIが変更になる可能性は減らすべきです。

他にもURIに関していろいろとあるようなので、またまとめていきたいと思います。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?