📝
Web API作成時のリソース設計の手順【基礎】
この記事では、Web APIを作るにあたってのリソースの設計とDB設計を行います。
今回は具体例として、SNSのAPIを作成するときの設計を取り上げています。
リソース志向アーキテクチャ
WEBサービスで利用するデータを特定する
SNSとなるとまず、ユーザー情報とフォロワー情報などがあげられるでしょう。
具体的には以下。
・ユーザID、ユーザー名、プロフィール、写真、誕生日など
・フォロワーID、フォローID
データをリソースに分ける
今回は上記の例からリソースを
１.ユーザーリソース（全ユーザーの情報を見る）
2.検索結果リソース（検索したユーザの情報を見る）
の２点に決定します。
リソースに URIで名前をつける
今回使用するURLは以下のように設定します。
| メソッド | URL | 詳細（リソース） |
|---|---|---|
| GET | api/v1/users | ユーザーリストの取得 |
| GET | api/v1/users/123 | 特定のユーザー情報の取得 |
| POST | api/v1/users | 新規ユーザーの作成 |
| PUT | api/v1/users/123 | ユーザー情報の更新 |
| DELETE | api/v1/users/123 | ユーザーの削除 |
| GET | api/v1/search?q=ryo | ユーザー検索結果の取得 |
意識すべきこと
・'api'という文字列をURLに含めるとAPIだということがわかりやすいのでつけるのが慣習
・'v1'や'1.1'のようにバージョンを入れておくのが慣習
・'users'のように名詞で定義する（api/v1/getusersのように無駄な動詞を入れない）
リソースの表現を設計する
データベース設計(Users テーブル)
以下のようにデータベースを設計する。
date_of_birthなどは、データベースによっては、TEXT型ではなくDATE型を入れられるかもしれないですが、
今回は簡略化のためにTEXTで行います。
| フィールド名 | データ型 | NULL許容 | その他 |
|---|---|---|---|
| id | INT | NOT NULL | PRIMARY KEY |
| name | TEXT | NOT NULL | |
| profile | TEXT | ||
| date_of_birth | TEXT | ||
| created_at | TEXT | NOT NULL | datetime関数で日付を取得 |
| updated_at | TEXT | NOT NULL | datetime関数で日付を取得 |
意識すべきこと
どのようなテーブルを作る時にも、created_atとupdated_atというフィールドは作っておく。あとでソートするときなどに非常に便利です。
Discussion