📝
Web API作成時のリソース設計の手順【基礎】
この記事では、Web APIを作るにあたってのリソースの設計とDB設計を行います。
今回は具体例として、SNSのAPIを作成するときの設計を取り上げています。
リソース志向アーキテクチャ
WEBサービスで利用するデータを特定する
SNSとなるとまず、ユーザー情報とフォロワー情報などがあげられるでしょう。
具体的には以下。
・ユーザID、ユーザー名、プロフィール、写真、誕生日など
・フォロワーID、フォローID
データをリソースに分ける
今回は上記の例からリソースを
1.ユーザーリソース(全ユーザーの情報を見る)
2.検索結果リソース(検索したユーザの情報を見る)
の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