API設計

WebAPI 設計のベストプラクティス

バージョンは URL に含めよう

レスポンスデータはラッピングすべきでない

フィルタ・ソート・検索はリクエストパラメータでやろう

作成・更新の後は変更後の情報をフルで返そう

ページング情報はレスポンスヘッダに入れよう

関連データを埋め込む手段を作ろう

トークン認証を使おう

-----

いろんなAPIをラッピングした、一つの大きなAPI

全APIを攻撃対象にされないか

スケールアウトしにくいのではないか

Adminに転送されるApiと一緒にするべきではない

サブドメインでApiを分けることはできるが

----

ドメインレベルはアプリとAPIで分ける。

アプリサーバーとAPIサーバー用のアプリケーションは同じでも良い。

アプリとAPI の負荷は異なる

個別にスケールアウト

API定義方針

簡易

post → 　　作成　→　　レスポンス 201 (リソース作成)

patch→　　一部更新→　200

put→　　　置き換え→　200

delete →　 削除 →　　204 （レスポンスデータ無し）

用語整理

REST

URIは其のリソースを表現する名詞

古いURIを新しいURIに転送する

言語を指定する拡張子

ステートフル

ステートレス

http

安全でもべき等でもないPOST

PUTやDELETEがべき等でなくなるケース

URIが差分や時間とか

このときはPUTやDELETEができないよう設計スべき

Digest認証

Basic認証よりセキュア

WSSE認証

microformats

キャッシュ用ヘッダー

キャッシュの有効期限の指定

API参考

qittaのapi設計が分かりやすい

github api

googleのリソース指向設計

Twitter

投稿に対しての画像アップロードと投稿は分けられている。