社内のLT用に作成した資料です

1. RESTfulなAPIの設計の
お話
Futoshi Takano

2. なぜREST?
RESTは設計時の制約が強い
→ 不特定多数の人が設計しても一貫性を担
保できる
→ 公開APIなど、不特定多数の人が用いる
API、複数の人が設計する時に向いている

3. ROA(Resource Oriented
Architecture)
RESTのAPI設計では、ROAという設計手法
が広く用いられている。

4. ROA(Resource Oriented
Architecture)の4つの概念
リソース
URI
表現（Representation）
リンク

5. ROA(Resource Oriented
Architecture)の４つの特徴
アドレス可能性
ステートレス性
接続性
統一インターフェース

7. リソースとURI
リソース： データとして表現できるもの。
リソースは名前とアドレスを与えるための
URIを持たなくてはならない。
https://qiita.com/api/v1/users/ftsan
GETでリクエスト送信すると・・・

8. リソースとURI
{
id: 19175,
url_name: “ftsan",
url: "http://qiita.com/ftsan",
description: “”, ….

9. 表現
リソースの表現はJSON形式。
{
id: 19175,
url_name: "ftsan",
url: "http://qiita.com/ftsan",
description: “”, ….

10. リンク
user: [
{id: 38270, url_name: “Takano”,….},
{id: 38271, url_name: “Futoshi”,….},….
http://aaa.test.com/v1/user/{id}
上記のようなURLの場合、idは個々のuserを指し
示すリンクであると言える。

11. アドレス可能性
提供する情報がURIを通して表現できる。
JSON Pointerを使ってJSON構造内のどのオ
ブジェクトを指し示すかを表現できる。
/data/0/id → dataは配列、左記のURLは
/data/0で表現されるデータのid

12. ステートレス性
APIリクエストのための情報がすべて独立・
分離していること。前提条件を必要としない。
→ セッションとかCookieを使わない。
ROAの場合はリソースはURIで与えられるた
め、自然とステートレスになる。

13. 接続性
リソースは別のリソースとの関連を表すリン
クを持ちうる

14. 統一インターフェース
リソースの操作をHTTPの標準のメソッドで
行う（GET, POST, PUT, DELETE) → 安全
性とべき等性を持つようになる

15. 統一インターフェース
リソースの操作をHTTPの標準のメソッドで
行う（GET, POST, PUT, DELETE) → 安全
性とべき等性を持つようになる
安全性 → サーバ側の状態を変更しない性質
べき等性 → 操作を何度繰り返しても同じ結果が返っ
てくる

16. 統一インターフェース
エラー表現にHTTPのステータスコードを利
用する。
200：OK → GET等のレスポンス成功時
404：Not Found → 存在しないリソースにア
クセスした時

17. 難しい・・・

18. 参考：WEB+DB PRESS Vol.82
http://gihyo.jp/magazine/wdpress/archive/2014/vol82
!
この本なんかも参考になるかと・・・
Webを支える技術 ── HTTP，URI，HTML，そして
REST
http://gihyo.jp/magazine/wdpress/plus/
978-4-7741-4204-3

19. ご清聴ありがとうございましたm(_ _)m