2008.4.12 RWS Reading

1. 第1回
RESTful
Webサービス
読書会

2. 自己紹介

3. kunit

4. 高橋邦彦
PHP
Programmer

5. Mapleという
Web Application
Framework を
作ってます

6. 次期バージョン
Maple4を
RESTfulにしたいと
思ってます

7. さて
本題へ

8. 第2章
Webサービス
クライアントの
作成

9. 2.1

10. Webサービスは
Webサイト

11. あらすじ

12. Webサービスに
便利な
ライブラリ

13. 常に
存在するとは
限らない

14. ので

15. HTTP
Requestと

16. HTTP
Responseを

17. 直接操作する
プログラムを

18. いろんな
言語で
書いてみよう

19. だが

20. いろんな
言語を
使って

21. 今日ここで
実行するのは
大変なので

22. 実際に
実行するのは

23. Ruby
のみです

24. RESTful
Webサービス

25. 基本的な
HTTP
クライアント

26. Yahoo!の
Web検索

27. ここで
実際に実行

28. このRubyの
サンプルでは

29. HTTP Requestの
送信

30. 標準ライブラリ
open-uri

31. 出力の解析

32. 標準ライブラリ
REXML

33. 一般化すると

34. （１）

35. HTTP Requestに
含めるデータを
考える

36. HTTP Method
URI
HTTP Header
Entity Body

37. （２）

38. dataを
HTTP Request
として
組み立てて

39. HTTP Server
送信

40. （３）

41. Response
dataを
解析

42. Response Code
Header
Entity Body

43. 第2章は
これをいろんな
言語で
やってみてます

44. けど
実演するのは
Rubyのみです
(くどいけど)

45. この章では
いちいち
この基本構造を
書くけど

46. ふつうは
ラッパーを
作成する
(か、あるものを使う)

47. いろんな
ラッパーが
用意されてるが

48. やりかた
ばらばら

49. WADL

50. Web
Application
Description
Language

51. RESTful
Serviceを
記述できる
語彙を持つ言語

52. SOAPでは
WSDL

53. ActiveResource

54. Ruby on Rails

55. Web Serviceの
クライアントの
作成が簡単

56. 第2章では
説明しないよ

57. 2.2

58. del.icio.us:
サンプルアプリケーション

59. ここからは
del.icio.usの
Web Serviceに
アクセスする

60. けど
del.icio.us
よくない！

61. del.icio.usの
Web Serivceの
設計は
RESTfulじゃない

62. https://api.del.icio.us/v1/posts/add
https://api.del.icio.us/v1/tags/rename

63. Requestは
全て
GET Method

64. URIに
動詞が登場

65. よろしくない

66. なぜ
del.icio.usを
選んだの？

67. （１）

68. 理解しやすい
よく知られてる
使いやすい

69. （２）

70. 記述的ではなく
規範的であることを
明確にするため

71. サーバは理想主義
クライアントは実用主義

72. 自分がすることには
保守的であれ。
他人から受け取るものには
寛容であれ。

73. （３）

74. ７章の
伏線

75. ７章では
ちゃんと
RESTfulに
つくるよ

76. これ以降の
サンプル

77. api.del.icio.usに
https接続して
GET /v1/posts/recent
をRequest

78. Responseを解析して
ブックマークの
href属性と
description属性を
標準出力に書き出す

79. 2.3

80. リクエストの作成：
HTTPライブラリ

81. いろんな言語の
HTTPライブラリを
紹介

82. 必要となる
機能

83. HTTPSと
SSL証明書の
検証

84. メソッドサポート
GET HEAD
POST PUT
DELETE

85. PUTまたはPOSTの
Entity Bodyとして
送信されるデータを
カスタマイズできる

86. HTTP Headerを
カスタマイズできる

87. Responseの
Entity Body以外に
Response Codeと
Headerにも
アクセスできる

88. HTTP Proxy経由で
通信できる

89. ここで
Rubyの
サンプル実演

90. 2.4

91. レスポンスの処理：
XMLパーサー

92. Web Serviceの
Entity Bodyは

93. 通常
XML Document

94. なので
XMLの
パースが必要

95. XMLパーサは
３種類ある

96. ドキュメント
ベースの手法

97. DOM

98. Document
Object
Model

99. 扱うのが
容易

100. ランダムに
アクセスが
できる

101. ただし
ドキュメント全体を
扱う必要がある

102. 大きな
ドキュメントだと
メモリを
大量に食う

103. イベントベース
の手法
（２種類）

104. ドキュメントベースの
手法に比べて
効率がよい

105. ただし
不正なXMLに
弱い

106. SAX

107. Simple API
for
XML

108. 複雑になるが
一部分だけ
扱いたいときに
便利

109. pull Parser

110. SAXより
扱いたい部分が
多い場合に便利

111. XMLパーサは
その時々で
使い分け

112. ここで
Rubyの
サンプル実演

113. 2.5

114. JSONパーサー：
直列化された
データの処理

115. Web Serviceが
返すドキュメントは
XMLだけじゃないよ

116. JSONで
単純なデータ構造
にして返すものが
増えてきた

117. 数値
配列
ハッシュ

118. なぜ
JSON？

119. Web Serviceを
受け取るのが
JavaScriptと
いうのが多いから

120. ここで
Rubyの
サンプル実演

121. もしかして

122. 筆者
JSON嫌い？

123. 2.6

124. WADLによる
クライアントの
簡易化

125. パターンがあるなら
もっと簡単に
扱えないの？

126. そこで

127. WADL

128. Web
Application
Description
Language

129. 詳しい説明は
９章まで待て

130. 何ヶ月後？

131. WADLの
導入は
進んでいない

132. なぜ？
（参加者に質問）

133. ここで
Rubyの
サンプル実演

134. 結論

135. Pythonの
人も呼びたい

136. ご静聴
ありがとう
ございました