はじめに
＊前回の続き
この記事は普段バックエンドエンジニアの方に作ってもらっている「WEB APIってそもそもなんだろう」という疑問から執筆しています。
「WEB API The Good Parts(水野 貴明 著)」を参考に自分なりにまとめアウトプットしていきます。
ぜひフロントエンドエンジニアの方で同じ疑問を持っている方は読み進めてみてください。
対象者
この記事は下記のような人を対象にしています。
- WEB APIについて何も知らない方
- フロントエンドエンジニアでWEB APIの触りの部分しか知らない方
それでは早速アウトプットに入っていきます。
レスポンスデータの設計
レスポンスデータ：リクエストの結果返されるデータのこと
まずデータフォーマットから見ていくらしいです。
- JSON
- XMLなど
ただ最近の傾向としてJSONのみに対応しているものも多くなってきており、必要に応じてXMLに対応するのがベストらしいです。
データの内部構造の考え方
例えばSNSのようなアプリで友達一覧を取得するAPIを作るとき、以下のようなデータだとどうでしょう？
ダメな例
{
"friends": [
1,
2,
3, ...
]
}
これだとIDのみしか取得できず、性別や名前、アイコンプロフィールなどを取得したいとき再度APIを叩かないといけなくなります。
いい例
{
"friends": [
{
"id": 1,
"name": "Taro Tanaka",
"profileIcon": "http://image~.png",
},
{
"id": 2,
"name": "Hanako Yamada",
"profileIcon": "http://image~.png",
},
]
}
上記のAPIだとアクセスも1回ですみます。
性別のデータをどう表すか
大きく分けて以下の2パターン
- "male"や"female"といった文字列として表現する方法
- 1なら男性、2なら女性といった数値で表現する方法
エラー表記
| ステータスコード | 意味 |
|---|---|
| 100番台 | 情報 |
| 200番台 | 成功 |
| 300番台 | リダイレクト |
| 400番台 | クライアントサイドに起因するエラー |
| 500番台 | サーバサイドに起因するエラー |
200番台のリクエストはクライアントからのリクエストが成功した場合しか返してはなら無いそうです。