1. Web APIの
これまでとこれから
2014-07-11 API Meetup #1
株式会社リコー 山本陽平

2. 自己紹介
• 山本陽平(@yohei)
• 株式会社リコー ネットワークアプライアンス
事業部VC設計センターPF設計室デバイスPFG
• 2000年入社、2008年からリコーUCSの開発
• 世の中的には「RESTの人」
2

3. REST(Web)と私

4. 1994-12 インターネットを知る
1995-01 初めてのWeb(Mosaic)
1998-04 NAIST入学
1999-03 第一回XML開発者の日
2000-04 就職
2000-11 SOAPを知る
2004-10 RESTをちゃんと調べる
2005-04 REST入門を書いた
2005-11第八回XML開発者の日
2006-04 WEB+DB PRESS Vol.32 特集3
2007-04 『RESTレシピ』連載開始
2007-12 『RESTful Web サービス』
2010-05 『Webを支える技術』
2014-07 API Meetup #1 ←イマココ

5. Q: 初めて使ったブラウザは？

6. Mosaic
Netscape Navigator
IE4未満
IE4-5*
IE6
IE7以降
Firefox(Firebird, Phoenix)
Safari
Chrome
Opera
ガラケーブラウザ
スマホブラウザ
その他

7. 本日お話したいこと

8. (今更RESTの話をしても仕方ないので)
8

9. 今日私達がWeb APIと呼んでい
るものの歴史を振り返り、そ
もそも何がしたかったのか、
それがどう実現されたのか、
これからどうなっていくのか、
についてお話しようと思います。
9

10. (RESTの最新状況は@tkawaさんに)
10

11. REST

12. UNIVERSITY OF CALIFORNIA, IRVINE
!
Architectural Styles and
the Design of Network-based Software Architectures
!
DISSERTATION
!
submitted in partial satisfaction of the requirements for the degree of
!
DOCTOR OF PHILOSOPHY
!
in Information and Computer Science
!
by
!
Roy Thomas Fielding
!
2000
http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

13. 2000 REST (RoyFドク論)

14. 1996 RFC 1945 HTTP/1.0
1997 RFC 2068 HTTP/1.1
1999 RFC 2616 HTTP/1.1
1999 RFC 2518 WebDAV
2000 REST (RoyFドク論)

15. 1998 XML-RPC
1999 SOAP 0.9, 1.0
2000 REST (RoyFドク論)
2000 SOAP 1.1, WSDL 1.0
2001 WSDL 1.1

16. 1998 XML 1.0
1999 XHTML 1.0
1999 RSS 0.9, RSS 0.91
2000 REST (RoyFドク論)
2000 RSS 1.0
2002 RSS 2.0
2005 OpenSearch 1.0

17. 2000年ごろのWeb
• プログラマブルなWebに関するいくつかの方向
性があった
• HTTPを拡張する(Writable Web)→WebDAV
• RPCを実装する→XML-RPC→SOAP
• プログラマブルなドキュメントを配布する→RSS
17

18. 我々は何を目指していたのか

19. XML, Java, そしてWebの将来(1997)
• 二つ以上の異種データベースの間を仲介するWebクライアントを必
要とするアプリケーション
• 処理の負荷の大部分を、WebサーバからWebクライアントに分散さ
せたいアプリケーション
• 同一のデータを、ユーザごとに別のビューで、Webクライアントが
表示することが必要なアプリケーション
• 情報をユーザが探すとき、インテリジェントなWebエージェントが
個々のユーザのニーズに合わせて処理をしてくれるアプリケーショ
ン
http://www.asahi-net.or.jp/~eb2m-mrt/Xmlapps.html

20. その後どうなったか
• データ連携→XMLを使う→JSONになった
• プロトコル→Webをどう使う？→いろいろな方
向性（HTTPをそのままと考えている人は少な
かった）→大戦争に
• クライアント→Javaアプレット→Flash?→ブラ
ウザ＋JS/スマホになった
20

21. 第八回XML開発者の日 山田さんの資料より
21

22. • Ajaxの発見→Google Maps, Livedoor
Reader→Single Page Application
• コードがクライアントサイドに移った
• サーバはデータを提供する
• ポータブルなクライアントがそれを処理す
る
• ブラウザが表示装置ではなくなった
22

23. データとコードの分離が進んだことで、ク
ライアントのバリエーションが増えた。
または
クライアントのバリエーションが増えたこ
とで、データとコードの分離が進んだ。
↓
全てがAPIに

24. 閑話休題

25. 黒歴史
• AtomPub→流行らなかった。CMS的な汎用
APIはあまり必要とされていなかった
• Description Language→出ては消え、出ては
消えの繰り返し。コード生成の儚い夢
25

26. 今後の展望

27. APIの本質的な価値
• プログラマブル（プログラム可能）になる
• プラットフォームがスケールする
• コストが下がる
• 今までコスト的にできなかったことができる
ようになる
27

28. 全てがAPIに

29. コンサンプションエコノミクス
所有から利用へ。初期投資はゼロ。
使った分だけ支払う→API重要
http://special.nikkeibp.co.jp/ts/article/ac0b/138322/

30. AWS

31. MBaaS

32. braintree

33. twilio

34. https://twitter.com/RonP/status/486647427227602944

35. • 本質でないところは他人にまかせる、が当然に
• そのプラットフォームは必ずAPIを持つ
• APIをRESTfulにするかどうかは要件しだい
• 要件に合ったアーキテクチャを
• 例：WebRTCはRESTじゃない
• APIの利用と開発は基本スキルに
35

36. 宣伝

37. リコーUCSというビデオ会議シス
テムで培った映像コミュニケーショ
ンのためのプラットフォームの公
開を計画しています。遅延の少な
い快適な映像コミュニケーション
に興味のある方は@RicohVCPを
フォローしてください

38. ☓@RichoVCP
☓@RicohVPC
⃝@RicohVCP

39. おわり