仕事で API を作ったので、そのときに調べたことなどのまとめです。

認証/認可

APIキー
OAuth2
basic認証
JWT（Json Web Token）
他にもあった気がする
一番シンプルなのはAPIキー
最近はOAuth2かJWTが主流っぽい
APIキーは実装も一番簡単だが、最近はセキュリティ的にOAuth2かJWT
（gitにAWSのAPIキーを乗せてしまってる人が結構いるとか何とか）

jail

不正アクセス対策
n回ログインに失敗したら一定時間ロックする

スロットリング

DDoS攻撃対策
負荷対策
一定期間に、一定回数以上リクエストがあった場合に弾く
想定ユーザ数が同時にその回数アクセスしたとして耐えられるか、Locust を使ってパフォーマンステストをした

APIのプロトコルについて

必ずhttpsを使う（暗号化する）
⇒認証情報などを盗み見される可能性があるため

APIのドメイン

もし既に画面（サービス）がある場合、ドメイン（サブドメイン）を分ける
（サーバの設定などを個別設定するなどのため）
https://app.service.co.jp/~~~
https://api.service.co.jp/~~~

メソッド

基本はhttpのメソッドに合わせる
GET：取得
POST：新規作成
PUT：更新
DELETE：削除
しかし、↑に当てはまらない場合もある（印刷、メール送信など）
その場合は決めの問題。
自分は↑以外は全てPOSTにした。
api/v1/member/print
など。
本来はuriに動詞を入れるべきではないが、現実にあわせて使う～でいいと思う。
ちなみに動詞が多くなる場合はそもそもRESTに向いてないので、RPCで作るのがいいかと。

ログ

既存のサービスがある場合、当たり前だが分ける
どのAPIが、どれくらい叩かれたか集計できるようにするといい
（誰が、どのAPIを、いつ、どれくらい･･･）

500エラーが起きた場合に、ちゃんとエラーメッセージを返す（生のスタックを返さない）
⇒エラーコードを発行しておくと、問い合わせ来たときにログを検索しやすくて便利

レスポンス

最近はjsonが多い
他はXMLとか
エンベロープに包むかは決めの問題
自分は包む方が好き
（API使う側で、結果の存在チェックをしなくて済むので）
エンベロープあり
“result” : {
“count” : “1”
}

エンベロープなし
“count” : “1”

ステータスコード

成功は200
（POSTの場合は201 created があるべきではあるが、ユーザから見て分けることによりメリットがあるか
⇒条件分岐を書く際に、ユーザが200と201を注意して書き分ける必要がある

エラーは4XX,5XX
通知することでユーザが何かアクションを取れるか、が重要
アクションを取れるのであれば4XX
取れないのであれば5XX
ぶっちゃけ、
成功：200
エラー：400
内部エラー：500
だけで、細かいことはメッセージなどで返す～でもいい
（自分が使う側だったとして、メッセージとコード両方あればメッセージを見る）

セキュリティ

Webサービスで必要な観点が大体必要な感じ
SQLインジェクションとか
チェックリストがあるので、これでチェックするといい
https://github.com/shieldfy/API-Security-Checklist/blob/master/README-ja.md

スケーリング

負荷テストして、どれくらいの負荷までサーバが耐えられるのか確認が必要
APIの用途によるが、負荷が上がったときにどうするかを考えておく
自動
手動
スケールアップ（スペックをあげる）
スケールイン（台数を増やす）
どこまで対応して、どこからは捨てるのか