REST (REpresentational State Transfer)

RESTの原則

• アドレス可能性(Addressability)
  • 提供する情報がURIを通して表現できること。全ての情報はURIで表現される一意なアドレスを持っていること。
• ステートレス性(Stateless)
  • HTTPをベースにしたステートレスなクライアント/サーバプロトコルであること。セッション等の状態管理はせず、やり取りされる情報はそれ自体で完結して解釈できること。
• 接続性(Connectability)
  • 情報の内部に、別の情報や(その情報の別の)状態へのリンクを含めることができること。
• 統一インターフェース(Uniform Interface)
  • 情報の操作(取得、作成、更新、削除)は全てHTTPメソッド(GET、POST、PUT、DELETE)を利用すること。

RESTful APIを使うメリット

1. URIに規律が生まれることで、APIを利用するサービス開発者が楽になる
2. URIに規律が生まれることで、API開発者もURIからソースのどの部分なのかが容易にわかる
3. ブラウザのアドレスバーにURIを入力すればリソースが参照できる
4. サーバ、クライアント間で何も共有しないことにより、負荷に応じたスケーラビリティが向上する。ステートレス性に値するもので、一番のメリットされている。
5. GET、POST、PUT、DELETE等のHTTP標準のメソッドを使うことで、シンプルで一貫性のあるリクエスト標準化が円滑に行える。統一インターフェースに値する。

RESTの設計原則であるRESTful

アドレス指定可能なURIで公開されていること

ex) https://qiita.com/api/v2/users/xxx

インターフェース(HTTPメソッドの利用)の統一がされていること

Method	処理
POST	登録
GET	取得
PUT	更新
DELETE	削除

ステートレスであること

「状態がない」

ステートレスなやり取りにおいてサーバーはクライアントのセッション情報を保持しません。

処理結果がHTTPステータスコードで通知されること

Code	状態
200	OK
201	Created
204	No Content
400	Bad Request
401	Unauthorized
403	Forbidden
404	Not Found
500	Internal Server Error