RESTful Meetup vol.3 Introduction
Upcoming SlideShare
Loading in...5
×
 

RESTful Meetup vol.3 Introduction

on

  • 2,387 views

書籍『RESTful Web APIs』の内容の紹介

書籍『RESTful Web APIs』の内容の紹介
http://sendagayarb.doorkeeper.jp/events/10103

Statistics

Views

Total Views
2,387
Views on SlideShare
844
Embed Views
1,543

Actions

Likes
5
Downloads
4
Comments
0

6 Embeds 1,543

http://d.hatena.ne.jp 1521
http://feedly.com 8
https://twitter.com 6
http://getpocket.com 5
http://translate.googleusercontent.com 2
http://www.feedspot.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

RESTful Meetup vol.3 Introduction RESTful Meetup vol.3 Introduction Presentation Transcript

  • RESTful Meetup vol.3 2014.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/name
 organizations.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/