Web API Design(その１) - winplusの日記
これApigee | Google Cloud Blogを勝手訳してみる。InfoQの紹介記事Web API Design - 開発者が愛するインターフェイスを作るで十分かも知れませんが、まあ。 導入 これを読んでいるということは、開発者に愛されるようなWeb API をデザインすることを気にかけているのでしょう。そして、実証済のデザインの原則とベストプラクティスとをWeb APIに適用することに関心があるのでしょう。 私たちがデザインを考えるのためのソースのひとつに、RESTがあります。なぜなら、RESTは厳格な標準ではなくアキーテクチュア・スタイルであり、かなりの柔軟さを認めているからです。構造が柔軟かつ自由であるからこそ、デザインのベスト・プラクティスを貪欲に追い求めるのです。 このe-bookはデザインのプラクティスを集めたものです。収録したプラクティスは、私たちがいくつかの世界中
営業日報とセマンティックウェブ - winplusの日記
思いつきだけ。 以前、営業日報の電子化システムのリニューアルを担当したことがあった。そのときの営業日報は非定型データーのかたまりというか、もちろん基本的な情報はあるにしても、最大かつ最重要な情報は自由入力欄に記入されるようになっていた。ところが、それでは分析とか再利用が困難だ。妥協案として、名称：値のペアを複数もてるようにして、それで検索や集計をできるようにした。あとで使う（であろう）情報は、その欄に記入してもらった。現在担当している全社データーベースにも営業情報が取り込まれている。こちらは事前に項目名を定めていないフラグと区分が大量に設けられており、以前に「名称：値のペア」として実装したのと同じように利用されている。 営業の実態を把握するためには検索や集計が可能でなければならないが、検索したいあるいは集計したい項目が事前には（設計時には）把握しきれない、ということだ。でも、全文検索だけで
要件におけるユーザーストーリーの利点 - winplusの日記
これの続きというか、Mike CohnのProject Advantages of User Stories as Requirementsを適当訳しておく。たんにまだ『User Stories Applied: For Agile Software Development』に手を出しかねているのだけなのだが。 ■要件におけるユーザーストーリーの利点 エクストリームプログラミング(XP)は、ユーザーストーリーの形式で要求を表現するというプラクティスを導入します。ユーザーストーリーは利用者の視点から語られた機能要件の短い説明です。機能要件とはソフトウェアの利用者あるいはソフトウェアの顧客のどちらかにとって価値があるものです。人材募集・検索サイトのための典型的なユーザーストーリーをあげましょう。 利用者は自身の履歴書をウェブサイトに掲示できます。 利用者は仕事を検索できます。 企業は新しい求人
Why using REST will kill your project - winplusの日記
タイトルに釣られて、Rant 3000: Why using REST will kill your projectを適当に翻訳しました。 RESTはおもしろい。でも、おもしろいものはたいてい、あなたを死なせることができます。まず最初に、RESTが何であるかを知らないのなら（恥ずかしいことではありません、というのも私はRESTが現われてから数年間、流行にとり残されていました）wikipediaの記事を見てください。RESTはクールなアイデアのように見えました。そして、私はRESTに従っていくつかのAPIを設計しました。しかしながら、RESTにはダークサイドがあったのです。それは致命的な場合があり、死なせることができて、たいていの場合、死なせてしまいました。大きなプロジェクトでも小さなプロジェクトでも。ここでは実際の例を使いますが、会社あるいは関係者の名前はふせておきます。 いまどきの２つの
RESTをどんなふうに説明するか - winplusの日記
http://tech.groups.yahoo.com/group/rest-discuss/messages/16621?threaded=1&m=e&var=1&tidx=1から適当に。 Sean Kennedy 私はアカデミーで働いていて、RESTfulな設計の利点について学生に伝えるために努力しています。私が最初にRESTに出会ったとき、それは以下の制約に従うスタイルとして説明されていました[1]。 すべてのものにIDをつける おたがいにものをリンクする 標準化されたメソッドをつかう 多重の表現 ステートレスなやりとり 私はこの夏、Royの論文を読みました。私なりに要約すると、次のようになります。 「RESTとは、他のネットワークベースのアーキテクチャスタイルから派生したハイブリッドスタイルです。アーキテクチャスタイルを使うことは、システムに関連する制約を適用することです。それぞ
『Webを支える技術』第3部 - winplusの日記
『Webを支える技術 -HTTP、URI、HTML、そしてREST』 第3部で、とくに面白かったところ。 ■HTTPの基本 HTTPの一番の特長はそのシンプルさです。 HTTPの重要な性質であるステートレス性 いわゆるwebサービスをつくる前に、これだけは知っていないと何もはじめられないことが実に簡潔にまとめてあります。ステートレスの利点と欠点（それとステートフルの利点と欠点）も分かりやすい。 ■HTTPメソッド たとえばログをリソースとして提供している場合は、ログに追記する操作はPOSTで行われるはずです。 たとえ「ログファイルへの追記」「ヒットカウンタの更新」が発生するとしても、GETは安全といえる。というのも、提供されているリソースは変更されていないから、という説明のあと、この文があって、すごく納得しました。 特別な理由がない限りは、リソースの作成はPOSTで行いURIもサーバ側で決
http://www.example.jp/にアクセスしてみた - winplusの日記
『Webを支える技術』第2部で、いちばん？「おお」とおもったところを書いていなかった。 ドメイン名example.jpは、......日本レジストリサービス（JPRS)が例示用に予約しているドメインです。 知らなかった。で、アクセスしてみた http://www.example.jp/ => サーバが見つかりませんでした http://www.example.co.jp/ => サーバが見つかりませんでした http://www.example.ne.jp/ =>サーバが見つかりませんでした http://www.example.org.jp/ => サーバが見つかりませんでした 当たり前か。気を取り直して次へ http://www.example.com/ You have reached this web page by typing "example.com", "example.n
ハックしやすいURIについて少し - winplusの日記
先日の記事に、ブックマークでコメントをいただいたので、少し。 # tkawa 「http://example.jp/users」もリソースになるね、とか考え始めたら「example.jp/users/」もリソースになるねというツッコミも可能。"/"にとらわれる必要もないし、提供しないなら403でいいと思う。パンくずリストはまた別の問題 まず、"/"付きのURLは想定外でした。コレクションのリソースを返す場合でも"/"なしのURLを使いそうだし、"/"付きのURLがリクエストされたら、403?404?にするのかな。それとも"/"なしにリダイレクトするか？ 『Webを支える技術』第2部に書いてあったらなあ、と責任逃れ。 id:tkawaさんのご指摘のとおり、想定されるすべてのリソースを提供すべきというのは無茶かもしれません。一方で、URLが（擬似的な？）階層構造になっているとすると、その途中も
『Webを支える技術』第2部 - winplusの日記
『Webを支える技術 -HTTP、URI、HTML、そしてREST』 第2部で、とくに面白かったところ。 URIはWebサービスやWeb APIの設計において最も重視すべきパーツであると言えるでしょう。 ■クールなURI 変わらない シンプル 覚えやすい もちろんURIを変わりにくくする指針もまとめられている。 この「シンプル」「覚えやすい」というのは、「リソースのセマンティクスがパスの見た目で自明ならフラットなほうが好み。」というid:yoheiさんのコメントと、とうぜん一致している。で、たぶん難しいのは「自明」の基準。id:IwamotoTakashiさんは第15章に掲載されているURIの例を「自明」でないと感じておられるようだし、それは理解できる。少し冗長であっても記述的なURIの方にひかれる。 ■URIの不透明性 WebサービスやWeb APIをハックして情報を勝手に取り出したいと
『Webを支える技術』第1部 - winplusの日記
『Webを支える技術 -HTTP、URI、HTML、そしてREST』 第1部で、とくに面白かったところ。 ■ハイパーメディアと分散システム ハイパーメディアとは、......さまざまなメディアをハイパーリンクで結び付けて構成したシステム Webは、世界中に配置されたサーバに世界中のブラウザがアクセスする分散システム たんにバラバラにコンピュータがあるだけでは分散システムとはいえないし、世界中にあるコンピュータを統一するなんて無理な話で、これらを結びつけるにはどうしても異種分散環境にならざるをえないんだけど、それにはシンプルでわかりやすい（そして実装も簡単な）単方向リンクで必要十分だった、ということ。 あたりまえなんだけど、リンク重要。Webはリンクでできている。「Webを支える技術」は、リンクをうまく機能させる技術なんだ......ちょっと言い過ぎかもしれない。 ■RESTと分散システム
『Webを支える技術 -HTTP、URI、HTML、そしてREST』の宣伝をしてきた - winplusの日記
4月7日 関西Javaエンジニアの会(関ジャバ) '10 4月度にいってきた。LTで「JAX-RS」と銘打って、中身はid:yoheiさんの『Webを支える技術 -HTTP、URI、HTML、そしてREST』の宣伝。 JAX-RS(LT)View more presentations from winplus. 興味をもってもらえたら、もうちょっと、ちゃんとJAX-RSを紹介しないと......。 ※お、一冊売れた。id:backpaper0さん、ありがとう。 ※発表の感想を忘れてました。簡単で、すみません。 ■Slim3 + GWT in Action(id:tan_go238さん) ・Slim3 全体はともかく、Slim3 Datastoreはいいかも。（JAX-RS推進派という立場なので。でも、GAEでJDOにこだわる必要はあるまい。） ・GWTはGWT-RPCなんですねえ（JAX-
HATEOAS - winplusの日記
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter9:HATEOAS」のメモ。目次はこちら インターネットが"Web"といわれるのは、一連のハイパーリンクで接続されているから。これによって、「サーフィン」できるし、サーチエンジンは巨大なインデックスを作成できる。 HTMLフォームは、もう一つの特徴。サーバーに情報を登録するには、ページをみて、それを埋めて、送信すればいい。HTMLフォームは自己記述的なやりとりをおこなう形式ということろが興味深い。 リンクとフォーム送信を記述するというアーキテクチャ上の原則は、HATEOASとよばれる。HATEOASとは、Hypermedia As The Engine Of Application
RESTfulサービスを設計する - winplusの日記
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter2:Designing RESTful Services」のメモ。目次はこちら この章では、簡単な注文入力サービスのRESTfulなインターフェイスを定義する。 オブジェクト・モデルからはじめて、まずURIを決め（アドレス可能性を満たす）、次にデータフォーマットを決め（表現指向）、最後にそれぞれのURIでどのHTTPメソッドを許可するかを決める（統一インターフェイス）。 ■オブジェクト・モデル 注文は特定の顧客に関連づけられ、いくつかの項目で構成される。項目は購入された商品の型と数量を表す。 モデルは、Order, Customer, LineItem, Product。どのモデルも
RESTへどうぞ - winplusの日記
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter1:Introduction to REST」のメモ。目次はこちら WWWは生活に欠かすことのできない一部分になっている。 でも、Webがうまくいっているのはなぜ？これほど巨大に成長できたのは？これだけ急速に拡がったのは？ Roy Fielding がこれらの疑問に答える形で、アーキテクチャの原則を特定した。これが REpresentational State Transfar(REST)。RESTの原則は以下のとおり。 到達可能なリソース RESTでは、情報（データ）のキーはリソースであり、すべてのリソースはURIで到達可能でなければならない。 統一され制約されたインターフェイス
『RESTful Java with JAX-RS』の目次 - winplusの日記
『RESTful Java with JAX-RS』が届いた。アマゾンに目次がのってないので、参考までに。 Foreword Preface PartI. REST and the JAX-RS Standard 1.Introduction to REST(RESTへどうぞ - winplusの日記) REST and Rebirth of HTTP RESTful Architectural Principles Wrapping Up 2.Designing RESTful Services(RESTfulサービスを設計する - winplusの日記) The Object Model Model the URIs Defining the Data Format Assigning HTTP Methods Wrapping Up 3.Your First JAX-RS Servi
ACIDからBASE（勝手に後半） - winplusの日記
先日の記事で触れたL'eclat des jours(2008-11-20)の続きを、勝手に試みた。調子を合わせようとしたけれど無理。全然こなれないし、誤訳もいっぱいあると思うが、参考までに公開しておく。 BASE：ACIDの代わりをどうぞ ■Consistency（一貫性）のパターンいくつか ブルーワのいうとおりなら、BASEは、分散と可用性をとるかわりに、どこかで一貫性を諦めるしかない。これは難しい。というのも、ビジネス関係者も開発者も「一貫性がいちばん重要だ」というんだ。一時的な矛盾であってもエンドユーザに見えてしまうので、ビジネス関係者と開発者の両方で、どこで一貫性を諦めるかを決める必要がある。 図2はBASEが考える一貫性を説明するための簡単なスキーマだ。userテーブルは、売上総額と購入総額も含めたユーザ情報をもっている。売上総額と購入総額は現時点での合計額だ。transact
CRUD型RESTの欠点と、読み取り可能なURI - winplusの日記
「CRUD型RESTの欠点」として挙げられている以下の点。 外部に見せているのは内部的なデータベース構造ないしデータであって、考え抜かれた契約ではありません。 本当のサービスを迂回して直接データにアクセスすることを助長します。 CRUDはRESTにとって良くないのか？ テーブルを知らないとSQLは使えない訳で、それをそのままマッピングするのはテーブルを公開しているのと同じ。これを利用するには、クライアント側が、すべてのビジネスロジックを把握する必要がある。 羊の皮をかぶったクライアント−サーバでしかありません。 CRUDはRESTにとって良くないのか？ 確かにね。 ちゃんとしたRESTfulなWebサービスであれば、クライアント側は一切のビジネスロジックを把握する必要がなくなると。そうであれば、必要かつ十分なWebサービスは、すべてハイパーリンクで提供される。つまり、クライアントがハイパー
30個の項目があって、そのうちの2個を消したくなったら(動画鑑賞 第1回RESTful本読書会 まとめ) - winplusの日記
やっと今日、第1回RESTful本読書会の動画鑑賞をおこないました。たしかに声が聞き取りにくいのですが、文字をみるのとは違い、雰囲気まで伝わってきて面白く鑑賞させていただきました。 http://kunit.jp/restful/wiki/index.php?%C2%E81%B2%F3%C6%C9%BD%F1%B2%F1%20%A4%DE%A4%C8%A4%E1 SQLステートメント SELECT INSERT UPDATE DELETE ストアド? HTTPメソッド GET POST PUT DELETE RPC呼び出し? id:kunitさんが、メタファーの危険性を指摘されていたにもかかわらず、あえて、このメタファーからの連想をメモしていきます。 ■すべてストアドで 上の表の最後の項目は、id:kunitさんのコメントから追加しました。RDBを操作する際にCRUDでは対応困難な状況が発
RESTful webサービス（７章 リベンジ） - winplusの日記
RESTful Webサービスのリベンジ。 ■７章 サービスの実装 サンプルが動かせなかったので（RESTful webサービス（７章は挫折） - winplusの日記）、リベンジに挑戦しました。 ■環境 ruby 1.8.6 (2007-06-07 patchlevel 36) [i486-linux] Rails 2.0.2 plugins/acts_as_taggable_on_steroids Rails2.0だと、http_authenticationは最初から入っている様子。 gemで、以下をインストール済み。 rest-open-uri (1.0.0) atom-tools (2.0.0) ■データベース(マイグレーション) p176 (例7-1) bookmarksテーブルのuser_idはinteger型に（sqlite3を使っているので、一緒なんだけど）。 user_b
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
新刊 - winplusの日記