"REST" is Fxxx.
What is REST?
で言及されている.
REST(Representational State Transfer)は、
・Null Style
・Client-Server
・Stateless
・Cache
・Uniform Interface
・Layered System
・Code-On-Demand
この制約を満たすほどRESTfullness
Core Conceptとしては、
Concepts | Description |
|---|---|
Resource | Entityの概念 |
Representation | JSON, XML, HTML |
HTTP Method | GET/POST/PUT/PATCH/DELETE ... |
HATEOAS | リソースに対する関連をリンクで返せる。 |
Content-Negotiation | 同じリソースに対するさまざまな表現、MIMEタイプ |
REST as API
REST APIとはRESTというアーキテクチャスタイルに従うAPI。
RESTアーキテクチャを実装するweb serviceはRESTful web API (RESTful API)としばしば呼ばれる。
REST API = RESTful API
What is Fxxx about RESTful API Design?
Limitation of Representation
表現の限界がある。
・GET
・POST
・PUT
・DELETE
他はあんまり使う機会ないと思うので、4つを抜粋。
HTTP REST APIとして特定のリソースとそのMethodを表現する場合、
/path/to/resource
となり、これに対する、参照(GET)・POST(作成)・PUT(更新)・DELETE(削除)を定義できる。
:
:
:
足りん！
例えば、Userというリソースがあった場合、
・参照 GET /users/hondaya
・作成 POST /users/hondaya
・更新 PUT /users/hondaya
・削除 DELETE /users/hondaya
が定義できる。このように綺麗におさまるユースケースなら良いが、
・POST /accounts/hondaya/transfer
・POST /orders/12345/pay
・POST /projects/bigbang-replace-backend/clone
などのエンドポイントを定義した際、HTTP Methodの表現にマッピングできないユースケースは途端にPathへの情報がもれ、リソース指向が破綻する。
Odd Status Code
401 (Unauthorized) / 403 (Forbidden) ????
まず認証と認可の説明として、
認証(Authentication)：ユーザーが本人かどうかを判断します
認可(Authorization)：ユーザーがアクセスできるもの、できないのものを判断します。
ref:
401のdescriptionとしてmozillaから引用する。
> 有効な認証資格情報が不足している
> ref:
"認証"が不足しているのに"Unauthorized"????
"""Forbidden"""????????????????
実はこれは、この議論自体はずっとされてるものらしく
2014年にietf-http-wgのMLで
RFC9110 HTTP Semantics:
まとめ
- RPC likeに全部POSTで /path/to/resource.{action}でやれば、リソースを綺麗なままmethod自体を自由に定義できる（個人的な主観）
- 401 UNAUTHENTICATED / 403 UNAUTHORIZED を返す。
- 仕様を決めるのはムズイ。文句を言う時は敬意を払って。