拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
rebuildfm 35のAPIの話が面白かった - wyukawa's diary
Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)の最後の方のAPIの話が面白かったのでそれについて書いてみる。 HTTP JSON APIにしろHiveServerが提供しているようなThrift APIにしろバックエンドにあるAPIサーバーにクライアントがアクセスして情報を取得してそれをもとに画面表示するっていうパターンは多いと思います。ここでいうクライアントってのは別にPCブラウザに限らなくてiPhoneやAndroidのようなスマートフォンだったりタブレットだったりいろんなケースがありえます。 iPhoneアプリでトップページを表示するのにAPIを10回叩く必要があるとかだと、レイテンシの問題もあるし開発の手間も増えますよね。そうじゃなくてiPhone専用のAPIみたいなのがあればそれ1回呼べば済むのでレイテンシの問題もなく
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
Web API認証について
最近、Web APIの認証をどうすべきか考えている。 例えば次のようなケースをどうするか。 「既存のWebサイトがあり、既にユーザＩＤとパスワードによる認証によって、ブラウザでデータを提供している。 今回、この提供データをブラウザの画面ではなく、REST APIにて取得可能にしたい。 このデータはユーザ毎に取得可能な値が違うので、認証、または認可によって制限をかけたい。」 ユーザーがブラウザからIDとパスワード(以下ID/PW)を使ってログインする方式を、そのままWeb APIにも適用しても安全なのだろうか。 Web APIの先にはスマホアプリやシェルスクリプトなどから直接ログインするものなどが考えられるが、安全かつシンプルに実装するにはどうしたらいいのだろうか。 私はセキュリティの専門家ではないので間違った考え方をしている可能性もあるが、誰かの目に留まって助言いただけるかもしれないので、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
