RestfulなAPIの設計のお話
- 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で与えられるた め、自然とステートレスになる。
- 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