¥Í¥Ã¥È¥ï¡¼¥¯¥×¥í¥°¥é¥ß¥ó¥°ÆÃÏÀ

第 11 回の目次

前回

: HTML5

今回

:

APIとサーバーサイドマッシュアップ REST型 API の設計論 OAuthによる認可 課題提出について 1 / 29

本日のソースコード

今までのソースを振り返る

weather

とか，

Yahoo

検索とか

What is API?

API: Application Program Interface

プラットフォーム機能をプログラムへどう見せるか

なぜ

API

が重要なのか

?

API

で何を見せるか

? (

何を見せないか

?)

どのようなアプリを作って欲しいか

どのような人に作って欲しいか

認証

(=

ユーザ管理

)

はどうするか

インターネットサービスにおいては

API

とはビジネスのあり方そのもの

3 / 29

FacebookとAPI

Facebook Server Browser Web Apps Server (3rd Party) 1. Facebook画面内で 3rd Party’s Appをクリック 2. アクセス 4. Iframe内で表示 API Facebook Library (PHP-SDK) App APIの主な機能

• Graph API （Social GraphにアクセスするAPI） • FQL (Facebook Query Language)

3. App実行 (PHP)

Categories of network service APIs

クライアント用

API

JavaScript型 JSをロードして関数 API を呼び出す．戻り値は JS のデータ． 直接 URI JSから URI を xhr で直接叩く (CORS がやりやすくなった)

サーバ用

API

SOAP型 複雑なメッセージをやり取りできる

WSDL (web services description language)でフォーマットを 定義 WSDLから自動的にプログラムを生成 REST型 簡単に使える (今日のテーマ)

返事での分類

JSON型/JSONP 型 XML型

その他

: WebHook

5 / 29

クライアント用 API の例 1: Google Adsense

<script type="text/javascript"> google_ad_client = "pub-123456789"; google_ad_width = 120; ... </script> <script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js"> </script>

クライアント用 API の例 2: Amazon Widget

<SCRIPT charset="utf-8" type="text/javascript" src="http://ws-fe.amazo n-adsystem.com/widgets/q?ServiceVersion=20070822&MarketPlace=JP&ID=V20 070822%2FJP%2Fwidgetsamazon-22%2F8009%2F9744abd0-deec-4332-ac5a-f514b5 bfd3e5&Operation=GetScriptTemplate"> </SCRIPT> <NOSCRIPT><A rel="nofol low" HREF="http://ws-fe.amazon-adsystem.com/widgets/q?ServiceVersion=2 0070822&MarketPlace=JP&ID=V20070822%2FJP%2Fwidgetsamazon-22%2F8009%2F9 744abd0-deec-4332-ac5a-f514b5bfd3e5&Operation=NoScript">Amazon.co.jp ウ ィジェット</A></NOSCRIPT>

【実験】

1

https://widgets.amazon.co.jp/

2

サーチウィジェットを選ぶ

3 http://www.sic.shibaura-it.ac.jp/~yamaken/temp/index.html 7 / 29

（Server-side）Mashup

サーバ

(

つまり

CGI)

が他のサイトのサーバ用

API

を利用して複

数のサービスを連携させること

(UA

，つまり

JS

でやるのは

Client-side Mashup

という

)

特徴

:

ドメインの壁を気にしなくて良い

大きな状態をもてる

(

ただし，まともなサーバが必要

)

ユーザの管理ができる

(

≒儲けられる

)

ユーザから見ると自分の情報をサーバに渡さなければならな

い

(OAuth

等もあるが

)

多くのサイトでは登録

ID

が必要

(

管理，課金，サーバ負荷軽

減等のため

)

サーバー用 API の例

API

一覧

http://mashupaward.jp/apis/

はてな

API

http://developer.hatena.ne.jp/

Twitter API

https://dev.twitter.com/rest/public

Yahoo API

http://developer.yahoo.co.jp/sitemap/

Amazon MWS API

http://developer.amazonservices.jp/

Google API

https://developers.google.com/apis-explorer/

https://developers.google.com/products/

Google Maps

の

Geocoding API

を呼んでみる

http://maps.googleapis.com/maps/api/geocode/json?address=1600 +Amphitheatre+Parkway,+Mountain+View,+CA&sensor=false

SOAP: Simple Object Access Protocol

SOAP

メッセージの例

<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <n:alertcontrol xmlns:n="http://example.org/alertcontrol"> <n:priority>1</n:priority> <n:expires>2001-06-22T14:00:00-05:00</n:expires> </n:alertcontrol> </env:Header> <env:Body> <m:alert xmlns:m="http://example.org/alert"> <m:msg>Pick up Mary at school at 2pm</m:msg> </m:alert>

</env:Body> </env:Envelope>

これをPOSTで送る．返事も似たような感じ．

フォーマットはWSDL (Web Services Description Language)で記述する

REST: Representational State Transfer

要は

URI

にアクセスするだけ

返事は，

XML

だったり，

JSON

だったり

SOAP

よりも簡単

REST

の特徴

(

こうなるように

API

を設計する

)

アドレス可能性

ステートレス性

接続性

統一インタフェース

11 / 29

Addressability

（アドレス可能性）

表記可能な文字列

(Address)

だけでリソースを指し示せること．

アドレス可能でない例

:

「

ftp.example.com

に

ftp

をかけ，

anonymous

ユーザでログイン

し，

pub

ディレクトリに移動して，

readme.txt

を取得する．

」

微妙な例

(

昔の

gmail):

https://mail.google.com/mail/?q=jellyfish&search=query&view=tl

これは

ajax

の中に隠されていた

今はこうなっている

:

https://mail.google.com/mail/#search/jellyfish

Statelessness

（ステートレス性）

すべての

http

リクエストが独立していること

│

│

各

http

リクエストにはその処理のために必要な情報がすべて含ま

れていること

最初の検索

:

http://www.google.co.jp/search?q=jellyfish

次の

10

件の検索

:

http://www.google.co.jp/search?q=jellyfish&start=10

過去の

”jellyfish”

検索に引き続く検索であるという状態はサーバー

側にはない

13 / 29

Advantages of Stateless API

HTTP

プロトコルの実装は簡単

(

タイムアウト処理，エラー

処理

)

負荷分散が容易

いつでもサービスの途中から実行可能

性能は多少落ちる

(

全情報を毎回送るから

)

Connectedness

（接続性）

リソースへの

URI

がハイパーメディアの中に記述されていること．

┌┐

└┘＼

┌┐

｜

┌┐

└┘┌┐

｜

└┘

┌┐

┌┐└┘

┌┐／

└┘

└┘

└┘

URI1

つだけ

Addressable

Addressable

not Connected

Connected

2

番目は，別のルール等を使って

URI

を生成する．

3

番目は，ハ

イパーメディアを解析すれば，その中に

URI

が入っている．

GData

の例

(

後述

)

link rel=

の例

Uniform Interface

（統一インタフェース）

基本的には以下の

4

つだけ

(

他に

HEAD

などもある

)

HTTP GET:

リソースの表現を取得する

HTTP PUT:

新リソース作成，既存リソース修正

HTTP POST:

新リソース作成．追加のようなイメージ．

HTTP DELETE:

リソースの削除

駄目な例

:

GET /addproduct?name=pencil&price=100

これは

GET

メソッドを使うべきではない

PUT

と POST

いずれもエンティティボディを伴う．何が違うか

?

PUT:

新規作成の

URI

や，修正対象の

URI

をクライアントが

正確に指定できる時に使う．

POST:

既存のリソースに従属する新リソースを作る．新リ

ソースの

URI

はサーバが決定する．

(

例

:

掲示板への投稿

)

実際には POST は，サーバー側で処理をさせるために気軽に使われるこ とが多い． 17 / 29

統一インタフェースが具備すべき性質

GET, PUT, DELETE

は次の性質を満たすように設計する

(HTTP

の仕様に書いてある

)

安全性

(safety)

GET (

と

HEAD)

は安全

=

リソースの取得のみをする

利用者は副作用を求めていないことの表明

必ず同じレスポンスという意味ではない→カウンター

べき等性

(idempotence)

GET, HEAD, PUT, DELETE

はべき等→何回実行しても同じ

2

回目の

PUT

は中身を上書き

2

回目の

DELETE

は空振り

副作用がないという意味ではない

メリット

:

信頼できないネットワーク

(

特にモバイル環境など

)

で，勝手にリトライできる．

POST

は，安全でもべき等でもない．

典型的な REST の例: GData (Google Data Protocol) リソースを参照・更新するプロトコル（Googleではもう使われていない） Atomの形式でデータをやりとりする →GET /myFeed ←200 OK <?xml version=’1.0’ encoding=’utf-8’?> <feed xmlns=’http://www.w3.org/2005/Atom’ xmlns:gd=∼ gd:etag=’W/"S0wCTlpIIip7ImA0X0QI"’> <title>Foo</title> <updated>2006-01-23T16:26:03-08:00</updated> <id>http://www.example.com/myFeed</id> <author> <name>Jo March</name> </author> <link href=’/myFeed’ rel=’self’/>

<entry gd:etag=’"CUUEQX47eCp7ImA9WxRVEkQ."’> <id>http://www.example.com/id/1</id>

<link rel=’edit’ href=’http://example.com/myFeed/1/’/>

<updated>2006-01-23T16:26:03-08:00</updated> <author> <name>Elizabeth Bennet</name> </author> <title type=’text’>Entry 1</title>

<content type=’text’>This is my entry</content> </entry>

GData

続き

データの更新は

rel=edit

のリンクへ

PUT

する

同じ

ETag

を指定する

→ PUT /myFeed/1/1/ <?xml version=’1.0’ encoding=’utf-8’?> <entry xmlns=’http://www.w3.org/2005/Atom’ xmlns:gd=’http://schemas.google.com/g/2005’ gd:etag=’"CUUEQX47eCp7ImA9WxRVEkQ."’> <id>http://www.example.com/id/1</id>

<link rel=’edit’ href=’http://example.com/myFeed/1/’/> <updated>2006-01-23T16:28:05-08:00</updated>

<author>

<name>Elizabeth Bennet</name> <email>liz@gmail.com</email> </author>

<title type=’text’>Entry 1</title>

<content type=’text’>This is my first entry.</content> </entry>

最近の話題: Open API Initiative

OAI: REST API

のインタフェース記述を広めるための組織

Swagger: OAI

で採用された

API

記述方法

例（

GitHub

の

aws-apigateway-importer

より）

:

{"swagger": "2.0",

"info": {"title": "API Gateway Test API",

"description": "Move your app forward with the Uber API", "version": "1.0.0"}, "host": "api.uber.com", "schemes": [ "https" ], "basePath": "/v1", "produces": [ "application/json" ], "paths": { "/products": { "get": {

"summary": "Product Types",

"description": "The Products endpoint returns∼", "parameters": [{"name": "latitude",

"in": "query",

"description": "Latitude component of location.", "required": true,

"type": "number", "format": "double"}, {"name": "longitude",

"in": "query",

"description": "Longitude component of location.", "required": true,

"type": "number", "format": "double"}],

参考: お勧めの本

Roy Fielding:

Architectural Styles and the Design of Network-based

Software Architectures

，博士論文

”REST”の提唱者．network-based なソフトウェアのアーキテク チャの分類学なども書いてある．

L. Richardson, S. Ruby

著，山本監訳

:

RESTful Web

サービス

,

オライリージャパン

水野著

:

AAA for service mashup

AAA: Authentication, Authorization, Accounting

サーバサイドマッシュアップでは，複数のサイト間で

AAA

を行

う必要がある．

クライアントサイドマッシュアップでは，単に UA 認証 (Cookie 等) を 利用するだけだった

OpenID: Authentication (

認証

)

のためのプロトコル．ある

サービスにアカウントをもつ利用者だということだけを証明

する．

OAuth: Authorization (

認可

)

のためのプロトコル．ある権利

を有する利用者だということだけを証明する．

マッシュアップでは，認証なしの認可だけで十分

(

なことが多い

)

→ ここでは

OAuth

を説明

23 / 29

OAuth 2.0

とは

OAuthは認可プロトコル（RFC6749）（2.0と1.0は違うので注意） ある3rd party (=client)の提供するサービスAには，あるユーザ(= owner)が利用するサービスBの情報(resource)が必要 ユーザはサービスAを使いたい clientにBの認証情報(パスワード)を教えたくない (もし教えたら，Bに関して何でもできてしまう) OAuthなら，3rd partyに自分の認証情報は教えずに，あるリソースに対するア クセスを認可(authorize)できる 用語

resource owner: resourceへのaccessを許可できる人

resource server (RS): resourceを提供するserver client: resourceをrequestするアプリ(=サービス) authorization server (AS): access tokenを発行するserver

注意: client̸= user agent (browser)．Web アプリだったり，ブラウザと は別のアプリだったり．

OAuth 2.0

のフロー

大雑把なフロー

1 clientをASに予め登録(原則として)

2 resource ownerはASに対して許可を出す

3 ASはaccess tokenをclientに発行

4 RSはclientからのaccess tokenに応じてresourceへの要求を許可

正確には4種類のフローが定義

Authorization Code: Clientが中心となって上記フローを実行

clientはWebサーバ上で動作(一番普通のパターン) Implicit Grant: 全部UA経由で実行

clientはJavaScript (@UA)で動作(Webサーバではないことに注意)

Resource Owner Password Credentials: RO認証情報を直接通信

clientにパスワードを教える(clientを100%信頼できるとき使う) Client Credentials: client自信がresource ownerの場合

clientプログラム固有の情報を管理する場合に使う(プログラム内の話)

上の2つのみ説明．Clientにどんな情報が渡るのかに注意．

要するにimplicitの方が高速，実装簡単，危険．

Authorization Code Flow

+---+ | Resource | | Owner | +---+ ^ | (B) +----|---+ Client Identifier +---+ | -+---(A)--- & Redirection URI ---->| | | User- | | Authorization | | Agent -+---(B)--- User authenticates --->| Server |

| | | | | -+---(C)--- Authorization Code ---<| | +-|----|---+ +---+ (A) (C) ^ v | | | | ^ v | | +---+ | | | |>---(D)-- Authorization Code ---’ | | Client | & Redirection URI |

| | |

| |<---(E)--- Access Token ---’ +---+ (w/ Optional Refresh Token)

Implicit Grant Flow

+---+ | Resource | | Owner | +---+ ^ | (B) +----|---+ Client Identifier +---+ | -+---(A)--- & Redirection URI ---->| | | User- | | Authorization | | Agent -|---(B)--- User authenticates --->| Server |

| | | |

| |<--(C)-- Redirection URI with --<| | | | Access Token in Fragment +---+ | |---+

| (F) |<---+ | | | (E) (D) +-|---+ | |

| | Script Redirection URI (A) (G)Access | without Fragment

| | Token | |

^ v ^ v

+---+ +---+ | | | Web-Hosted | | Client | |Client Resource| +---+ +---+

IDs used in Smartphone Services

結局「紐付け」，つまりIDがキモ．例えばスマホでは以下のIDがある．

iPhone

IMEI (電話番号): 取得できない

MACアドレス: 今では取得できない

Cookie: Safariのデフォルトは3rd party cookieオフ

UDID (Unique Device Identifier): 今では取得できない

Advertising Identifier: 端末固有の番号

広告にしか使えない．利用者が利用拒否やリセットできる．

Identifier for Vendor: ベンダー毎に固有の番号

UUID:アプリで生成できる乱数 UIID:アプリごとの固有番号．UUIDを保存しているだけ? Android Android ID:端末初期化時番号 取得は可能だが広告目的に使ってはいけない IMEI:許可があれば取得できる MACアドレス: 取得できない

AdvertisingID: AppleのAdvertising Idと同じ

課題提出について

課題: 本授業で説明した技術を用いた通信アプリ (新規性は問わない) 例: サーバー用 API を使ったアプリ HTML5の新機能を使ったアプリ サーバーで何か工夫したアプリ (Web サーバ立てました，は駄目) 実装方法: 自分で環境を設定できる場合: Apache/Tomcat/Node.js/Rails等を立てて何かする 大学の PC だけで何とかする場合: 無料の外部サーバを使う IaaS:例えば Amazon EC2 PaaS:例えば Heroku

MyVolume上の public html にページを作ってブラウザで開く JSで (google や Twitter などの) API を呼び何かを作る 提出方法: 第 15 回 (2015 年 1 月 14 日) に発表 アプリの概要とシステム構成等をパワーポイントで発表 (発表しなかったら不可) 数日以内に以下を提出 (正確な〆切りは当日通知) 上記パワポ + ソースコード + 詳細説明 または ソース中のコメント （ソースコードの中のパワードや ID は”xxxx”などとすること） 29 / 29