TwitterのURL設計
先日書いたTwitterのER図作成の課題↓
この次に、URL設計の課題があります。これまた何度も修正して難関だったのでポイントをまとめる。
要件
<例>
| Method | Path | Description |
|---|---|---|
| GET | /tweet/new | ツイート作成画面を表示する |
| POST | /tweet | ツイートを投稿する |
参考資料
- REST入門 基礎知識 - Qiita
- PUT か POST か PATCH か？ - Qiita
- RESTful APIのURI設計(エンドポイント設計) - Qiita
- Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) | 山本 陽平 |本 | 通販 | Amazon
ポイント
POSTとPUTのどちらか
ざっくりとまとめると、
PUT：リソース名を指定して作成・更新、べき等である
POST：新たにURLが割り振られる、べき等でない
リツイートやリプライやいいねやブックマークはリソースの作成になるのでPOST。最初はみんな悩むよね...
機能にあった名前をつける
他の人がみて意図が伝わる名前にすること。
- 例：
POST /home ツイートを投稿する
homeを作成する意味にとらえられてしまう。
"top"とか"home"とかあってもなくてもいいような名前は、場合によるが基本的にはつけなくていい。
- 例：
DELETE /list_id リストを削除する,DELETE /tweet_id ツイートを削除する
この2つは一見似たような作りになってしまうため/list/list-idなどとすべき。
URLはなるべく短く！としか考えてなかった...
idの位置
編集や削除のときにURLにidが含まれる場合、idをどの位置に入れればいいのか問題。
例えばメモを編集する場合、memos/id/editという形が基本形
DB設計にあわせる
当たり前の話で恐縮なんですが、、今回のTwitterのURL設計でいうとその前にER図を自分で作成しています。 上に書いた
リツイートやリプライやいいねやブックマークはリソースの作成になるのでPOST
というのは、自分でそういうDB設計をしたから。そういうことを一切頭に入れずにこのURL作成の課題に取り組んでた...流れを理解するって大事。
