RESTful Meetup vol.32014.04.12

Venue provided by SonicGarden Inc.

『RESTful Web APIs』読書会と内容の紹介

Introduction of the reading group and a brief summary of “RESTful Web APIs”

『RESTful Web APIs』読書会

The reading group of “RESTful Web APIs”

• 毎月第2・第4木曜日の19:30～22:00にここで開催しています。

• モニターに本を映して、主に @tkawa が簡単な日本語訳を読んでいきつつ、みんなで気になったことや疑問点などを話し合って理解を深めます。

Meetup on the 2nd and the 4th Thursdays every month in this place Displaying the text and its rough Japanese translation, we discuss what interests us, what we don't know, etc.

本とノベルティをいただきました。ありがとうございます！

We received the books and novelties from @mamund. Thank you very much!

• 2013.09.27 Release the book • 2013.10.10 Reading Meetup #1 • 2013.10.24 #2 • 2013.11.14 #3 • 2013.11.28 #4 • 2013.12.12 #5 • 2014.01.09 #6 • 2014.01.23 #7 • 2014.02.13 #8 • 2014.02.27 #9 • 2014.03.13 #10 • 2014.03.27 #11

• 1回にだいたい1章進みます。（長い章は2回に分ける）

• ほぼ9章まで進みました。

About one chapter at a time We’ve progressed to chapter 9 until now

次回

• 2014.04.24 #12

• http://www.circleaf.com/events/115

• RESTやWeb APIに興味のある方の参加をお待ちしています。

Next

Sendagaya.rb

• 地域Rubyコミュニティ

• 隔週月曜日の19:30～21:30にここで開催しています。

• Next: 2014.04.28 #79 http://sendagayarb.doorkeeper.jp/events/10452

Regional Rubyist community Meetup on every other Monday, also in this place

http://sendagayarb.doorkeeper.jp/

Brief summary of “RESTful Web APIs”

REST・ハイパーメディアとそれを利用した設計手法

この本に書いてあること

This book explains REST, Hypermedia and the design procedure using them.

何ができるのか？ 何が解決するのか？

そもそも今なにが問題なのか？

What can you do and what do you solve with this knowledge?

What is a problem in the first place?

– 第3章より

RESTはプロトコルやファイルフォーマットや開発フレームワークではありません。設計の制約の集合です。

“REST is not a protocol, a file format, or a development framework. It’s a set of design constraints.”

“

RESTとは

Webがうまく動くようにするためのしくみ

RESTとは、大ざっぱにいうと

Roughly speaking, REST is the mechanism that makes the Web work well.

だがしかし 既存の Web API って

うまく動いていないところがあるのでは？

Today’s APIs don’t work well, do they?

– Introductionより

現在のほとんどのAPIには、大きな問題があります。一度公開したら変更することができません。業界が変化しつつも、何年も変わらない有名なAPIがたくさんあります。変更があまりにも困難だからです。

“Most of today’s APIs have a big problem: once deployed, they can’t change. There are big-name APIs that stay static for years at a time, as the industry

changes around them, because changing them would be too difficult.”

APIの問題 (1)APIs can’t change

“

– Introductionより

“Twitter API”、“Facebook API”、“Google+ API”、この3つのAPIは、同様のことを行います。すべてユーザーアカウントの概念を持っているし、ユーザーがテキストを自分のアカウントに投稿します。しかし、それぞれのAPIは完全に異なる設計を持っています。1つのAPIを学んで

も、他のものには役に立ちません。

“We talk about the “Twitter API,” the “Facebook API,” and the “Google+ API.” These three APIs do similar things. They all have some notion of user accounts

and (among other things) they all let users post a little bit of text to their accounts. But each API has a completely different design. Learning one API

doesn’t help you learn the next one.”

APIの問題 (2)

“Duplication of Effort

本来、RESTは変更をうまく扱えるし、 同じ意味のものは同じやり方で

扱えるはず

RESTful architectures are designed for managing change in themselves.

なぜうまくいってない？

Why do they have problems?

RESTの要素である「ハイパーメディア」をちゃんと使えていないから

Because they don’t use hypermedia properly.

– Introductionより

ハイパーメディアはWeb APIが変更をうまく扱えるようにする機能です。 『RESTful Web APIs』は実質的にはハイパーメディアについての本です。

“hypermedia is the feature that makes a web API capable of handling changes gracefully.”

“RESTful Web APIs is effectively a book about hypermedia.”

“

ハイパーメディア == リンク

Hypermedia == Link

ハイパーメディアは Web APIに柔軟性を あたえてくれる

Hypermedia gives web APIs flexibility.

ハイパーメディアを使うと「意味付け」ができる

Hypermedia has ability of “giving the meanings”

意味を表す名前• 値の意味を表す名前 (Semantic Descriptor) • リンクの意味を表す名前 (Link Relation)

Person, name, memberOf

<!-- http://example.com/people/135 --><div class="Person"><span class="name">Toru Kawamura</span>Member of <a href="/organizations/32" rel="memberOf">Sendagaya.rb</a></div>

意味付けリンクを使って「標準語彙」に結びつける こうすれば、標準語彙さえわかっていれば「意味」がわかる！

<!-- http://example.com/people/135 --><link href="http://alps.io/schema.org/Person" rel="profile"><div class="Person"><span class="name">Toru Kawamura</span>Member of <a href="/organizations/32" rel="memberOf">Sendagaya.rb</a></div>

Person → http://schema.org/Person name → http://schema.org/name memberOf → http://schema.org/memberOf

You can connect it with the “standard vocabulary” using a link. This gives understanding of the application semantics to a computer

with understanding of the vocabulary.

夢の世界

person = Person.find('http://example.com/people/135')# fetch http://example.com/people/135# => <ActiveNantoka::Person>person.items_for('http://schema.org/name')# => ["Toru Kawamura"]person.links_for('http://schema.org/memberOf')# fetch http://example.com/organizations/32# => [<ActiveNantoka::Organization>]

「標準語彙名(standard vocabulary)」で値やリンクを取得できる リンクは has_one/has_many 的リレーションに

Imagine…

何がうれしい？

{ "fullname" : "Toru Kawamura", "organizations" : [ { "title" : "Sendagaya.rb", "url" : "/organizations/32" } ]}

fullname → http://schema.org/nameorganizations.url → http://schema.org/memberOf

JSONでも標準語彙に結びつけてあれば、全く同様に扱える！ 「意味」が同じであれば、APIの構造が違っても同一のインターフェイスで扱える

ハイパーメディアをちゃんと使えば

• APIのフォーマットや構造に依存しない変更してもクライアントが壊れない

• クライアントがさまざまなAPIの中の情報を適切に扱える

Using hypermedia properly, clients won’t break

– Introductionより

ハイパーメディアは、RESTのまさに最も重要な側面であり、最も理解されていないものです。

“hypermedia is the single most important aspect of REST, and the least understood.”

“

その考え方がこの本にはまとまっています！

Those ideas are collected in this book.

http://restfulwebapis.com/