[A-00207] API設計・実装入門
APIについて深く考える為の記事です。基本的には入門用の記事を目指して書いておりますが、用語などは知っている前提で記載するので適宜調べていただければと思います。
・RestAPIの設計について
APIの代表例のRestAPIの設計について考える
・URI設計(Endpoint)について
とりあえずルール的なところ、常識的なところについて押さえておく
- FQDN含めuri内で名称の重複がないこと(apiという単語が複数出てくるなど)
- 基本的に大文字は使用しない
- サーバーの内部処理が表現されないこと(例えばbulkとかbatchとかユーザーの関心がない言葉は使わない)
- version番号が含まれている
- リソースにアクセスするapiは複数形を用いる
- 検索する場合には[search]という単語を用いる(findではないことに注意)
- ケバブケースを用いる(2つ以上の単語はハイフンで繋ぐ)
- RestAPIはResourceOrientedArchitecture(ROA, リソース指向アーキテクチャ)であると認識する
- URIは構造的かつ直感性を備えている必要がある
他社のAPI-Endpointのサンプルは下記の通り
社名 | method | Endpoint |
---|---|---|
X(Twitter) | GET | https://api.twitter.com/2/tweets/search/all |
X(Twitter) | GET | https://api.twitter.com/2/users/by/username/USER_NAME |
X(Twitter) | GET | https://api.twitter.com/2/users/USER_ID/tweets |
OpenWeatherMap | GET | https://api.openweathermap.org/data/2.5/weather?lat={lat}&lon={lon} |
OpenWeatherMap | GET | https://pro.openweathermap.org/data/2.5/forecast/climate?lat={lat}&lon={lon} |
・ROA(ResourceOrientedArchitecture(リソース指向アーキテクチャ))について
リソースに対する思想です。基本的にこの思想を元にAPIを作成します。
- リソースは必ずURIを持つ
- RestAPIを提供するアプリケーションにはアドレス可能性がなくてはならない(URIを通じて簡単にリソースに辿り着ける事)
- ステートレスでなくてはならない(全てのHTTPリクエストは完全に独立している。リクエストAを実行したのちにリクエストBを実行すると、リクエストBを最初に実行した時と振る舞いが変わる、ということになってはならない)
- 冪等性を備えなくてはならない
- リソース状態、アプリケーション状態の二つがある
- 接続性を持たせる(リソースは他のリソースへのリンクを持たせることができる)
・HTTPメソッドについて
RestAPIにおけるHTTPメソッドは下記のようなものがある
HTTPメソッド | リクエスト | レスポンス | 操作 |
---|---|---|---|
GET | パスパラメータ or クエリパラメータ | レスポンスボディで返却 | リソースの取得 |
PUT | リクエストボディ, パスパラメータ | 空のレスポンスボディ | リソース(全体)の更新、作成 |
PATCH | リクエストボディ,パスパラメータ | 空のレスポンスボディ | リソース(部分)の更新 |
POST | リクエストボディ | レスポンスボディ | リソースの作成 |
DELETE | レスポンスボディにメッセージ付きで返却 | リソースの削除 | |
HEAD | リソースのメタデータの取得 | ||
OPTIONS | リソースがサポートするメソッドの参照 |
・HTTPステータスコードの設計
RestAPIサーバーからクライアントへ返すHTTPステータスコードについて記載する。
ステータスコード | Method | Success/Error | 説明 |
---|---|---|---|
200 OK | GET,POST,PUT,DELETE | 成功(Success) | リクエストが成功して正常なレスポンスがクライアントに返却された場合に使用 |
201 Created | POST | 成功(Success) | リクエストが成功して新しいリソースが作成された場合に使用 |
・Appendix
参考文献はこちら
https://qiita.com/NagaokaKenichi/items/6298eb8960570c7ad2e9
https://qiita.com/NagaokaKenichi/items/0f3a55e422d5cc9f1b9c
https://qiita.com/NagaokaKenichi/items/df4c8455ab527aeacf02
https://qiita.com/uenosy/items/ba9dbc70781bddc4a491
https://qiita.com/Shokorep/items/b7697a146cbb1c3e9f0b
https://apidog.com/jp/blog/introduction-to-api-parameters
https://qiita.com/teinen_qiita/items/e440ca7b1b52ec918f1b
https://qiita.com/KNR109/items/7e094dba6bcf37ed73cf
https://qiita.com/lvn-okino/items/df16b0922dff67443d38
https://qiita.com/baby-degu/items/6f516189445d98ddbb7d
https://zenn.dev/knm/articles/32106f623bd382
https://qiita.com/uenosy/items/ba9dbc70781bddc4a491
https://zenn.dev/sgtkuc1118/articles/c73587c674a4a2
https://zenn.dev/altiveinc/articles/generate-code-from-openapi
https://future-architect.github.io/articles/20210518a
https://omathin.com/swagger-editor-design-firststep
https://www.strategit.jp/column/041304
https://zenn.dev/peraichi_blog/articles/01ges56ak79g2rket9wm27w9pc
https://zenn.dev/syy/scraps/fe0fead12046c2
https://learn.microsoft.com/ja-jp/azure/architecture/best-practices/api-design
コメントを残す