1
Help us understand the problem. What are the problem?

posted at

updated at

URIへの意識とCool URI

はじめに

これはTreasure Advent Calendar 2019の15日目のポエムっぽいナニカです。(1日遅れてごめんなさい)
こういう投稿自体初なので、温かい目で見守っていただけるとありがたいです。

お前は誰

Web系でぼちぼちインターンをしたりしてきたB3の学生です。
就活真っ只中で自分のCS基礎力の低さを目の当たりにしたので、本とか読んで再勉強中です。
今回の内容に関してはWebを支える技術を読んで勉強させていただきました。感謝🙏

何についてのポエムか

本に出てきて今までない知識だったURIのお話と、URI設計でよいとされているCool URIについて。

本題

みなさんURIって聞いたことがありましたか?
URLはよく聞きますが、日常から耳にするわけではないと思います(自分だけかも)。

URIとURLの違いについて書こうと思ったのですが、とてもいい感じにまとめてくださっている記事があるので読んでいただくとわかるかと思います。

超ざっくりと用語説明

URI(Uniform Resource Identifier)
・ URLとURNをあわせて呼ぶときの名前

URL(Uniform Resource Locator)
・ リソースの場所を示すもの

URN(Uniform Resource Name)
・ URLだけでは更新されるとリソースにたどり着けないので、ドメイン名などから独立してつけられる名前

URIの方が広義なので、URLやURNのことをURIと呼んでもいいらしいです。
ただ、URIはそもそもIdentifierで、これらセットで初めて示すリソースが一意に定まるのでは?と思っているのでちゃんと呼び分けていきたいな〜と思ったりしてます。

Cool URI

今回一番話したかったのはこれ。
これはいったいどういうものなのかというと、

クールなURIとは変わらないもののこと。
クールなURIは変わらないより引用。

ここに言われているように、変わらないURIこそが良いURIであるという考え方です。

<!-- ここからガチポエム -->

今まで僕は、他人がそのURLを見て、リソースがどんなものなのか、何をしているかが明確にわかるものがいいURLだ!と思ってAPIを作ってきました。
しかしこれは目先の見やすさ、開発のしやすさだけを考えた決め方になっていたのですねぇ。

じゃあ何を根拠に変わらないことが良しとされているのか?
それはユーザの気持ちになればわかるというものです。
ユーザーはURLが変わったことなんて知る由もないですし、知ろうとも思わないのです。(お知らせを出せば話は変わるでしょうが…)

また、皆さんリンク切れに出くわすととんでもなくテンション下がりますよね、僕は出くわした瞬間にそのサイトを信頼しなくなります。
なので恒久的にアクセスできることと、信頼性は超密接なものであると思います。

安定的にユーザーに使ってもらい、サービスを成長させようとするならば、CoolURIをしっかりと意識すべきなんじゃないかと思ったわけです。

不変のURI実現のために必要なこと

まずはこれらをURIに含めないことが求められています。

  • 作者名
  • 件名
  • 状態
  • アクセス権
  • ファイル名の拡張子
  • ソフトウェアのメカニズム
  • ディスク名
  • 上記はクールなURIは変わらないより引用

さらに、本で学ばせていただいた教訓として、実装に依存するものも含めてはいけないということ、名詞を使うことなどもありました。
実装に依存するものとして、僕が犯していた間違いの中で最も大きいと考えたのは、メソッド名を含めてしまうというものです。

これは例ですが、
サービス利用者の購入済み商品を返すAPIとして、purchased_itemという名前のものを作ったとします。
user has many items だと思って進んで下さい。

そうすると今までの僕のやり方で行けば
https://hogehoge.com/users/1/items/purchased_item
とかになるんでしょうが、これはメソッド名を含めてしまっていて良くないということにますね。
(命名がクソとかは置いといて、、、)

ただ、こればっかりはしょうがないんじゃないか?と思いました。
ただのサイトならメソッド名を含めずとも実装し切ると思いますが、特定の条件のものを引っ張ってくるためにAPI作ったんだし名前に含めても、、、と。

ただよく考えてみると、購入物はしばしば英語の名詞でpurchasesと表されるので、itemsとは別にpurchasesというテーブルを用意して、購入済みのもののidとか入れておいて、
https://hogehoge.com/users/1/purchases
とかにすることができます。
これによってテーブルが増えるのがネックな気はしますが、いまのCoolURIを目指す僕にとってこんなものは壁ではないのです。(これが正しいかは教えて下さい偉い人🙏)

これにより僕の最初に作ろうとしたクソURLはおそらくCoolになりました。
これを最初から知っていたらそもそもDBの設計から変わってくる話かもしれないので、覚えておいて損はないなってことでご紹介しました。
CoolURIでした。

また、API設計について色々調べてみると、世の中には僕の疑問を解決してくれるありがたいものがありました。
ここにあるスライドの33pの考えに習うと、まだ他にもURLの設計ができるのでは?と思いとても楽しそうだと思いました。

終わりに

個人的な理由で時間もなく、かなり浅いポエムとなってしまいましたが、自分が今まで意識してこなかったURIの設計やCoolなやり方について少しでも共有できてたら嬉しいです。
あと、フレームワークを使ってるとあまり意識せずにきれいになってることもあると思うので、先人の偉大さに感動したりもしました。

間違い箇所等ありましたら教えていただけるとありがたいです。
以上!初ポエムでした!

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Sign upLogin
1
Help us understand the problem. What are the problem?