なにこれ
REST APIについて調べ直したときの個人用のメモ
リソースとは
データベースの行など
ROA（リソース指向アーキテクチャ）とは
参照するものをリソースとして、リソースを中心に考えるアーキテクチャ
リソースはURIを持つ(/products)
リソースに対する操作（GET, POST)
リソースの表現形式(言語, JSON, etc)
URI
リソースは1つ以上のURIを持つ
URIは記述的にしろ
/products/1 みたいな
/products1.1 と /products/latest は同じリソースを返すかもだけど、
概念が違うのでURIが2つでok
（前者はバージョン固定、後者は最新版）
ステートレス性
全てのHTTPリクエストが完全に分離している性質をステートレス性という
サーバー側でアプリケーション状態の管理をしない
クライアントが送信するHTTPリクエストに、サーバーが処理するための必要な情報が全て含まれてて、以前のリクエスト情報にも依存しない
リソース状態
サーバーで維持される状態のこと
統一インターフェース
GET リソースの取得
PUT リソースの更新
POST リソースの作成
DELETE リソースの削除
HEAD リソースのメタデータの取得
OPTIONS リソースがサポートするメソッドを調べる
GET /getResource じゃなくて GET /resource の方が一貫（統一）したインターフェースを保証できる
GET
- GETリクエストを送信してリソースを取得する
- response.bodyでリソースを持つ
DELETE
- 不要なリソースを削除するために、DELETEリクエストを送信してリソースを削除する
- response.bodyはステータスメッセージ or 空である
PUT
- 新規リソースの作成
- 既存リソースの更新
POST
- 親リソースに対して子リソースの作成 /products/1/entries/1 みたいな
- 既存リソースへの状態の追加
- オーバーロードPOST
HEADとOPTIONS
HEAD
リソースのメタデータを取得（サイズ、更新日時など）
OPTIONS
リソースがサポートしてるHTTPメソッドなどを調べられる。
「Allow: GET, HEAD」のような形でレスポンスヘッダーにAllowヘッダーが含まれてる
分かったこと
取得するリソースが分かるようなURI名をつける！
e.g.
POST /users/1/products
POST /users/1/products/validate
みたいなURI名は微妙。
POSTメソッドなのにvalidationをするだけのエンドポイントは無駄ってかリソース取得の考え方と違う
paramsにsave: falseっていうfieldを追加して、
controllerで判別するべき？
余談
- resouceに含めてはいけないレスポンスもある（emailなどユーザーの個人情報）