非同期プロトコルのクライアント - sdyuki-devel
非同期プロトコルとは、サーバーから返ってくる応答が、必ずしも要求した順番通りに返ってこないプロトコル（ソース無し。オレオレ定義）。 順不同で返ってくる応答と要求を対応づけるのはクライアントの仕事で、典型的には要求の中にシーケンス番号を入れておき、サーバーは要求と同じシーケンス番号を応答の中にも含める。 例：MessagePack-RPC 非同期プロトコルの特徴： イベント駆動型のサーバーの場合、サーバーの実装が簡単になる 同期プロトコルだと順番を揃えてから返さないといけない。サーバーの実装が（要求１つに対してスレッドを割り当てて処理するのではなく）ソケット１つに対してスレッドを割り当てて処理する方式だとあまり関係なくて、特に実装は簡単にならない。 処理が重い要求と軽い要求を続けて送っても、重い要求に詰まって後の応答が返ってこなくなることが無い 同期プロトコルだと、応答を送り返すにはその前の
最小抽象ファイルシステムで何をしたいのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
最小抽象ファイルシステム（Minimum Abstract Filesystem; mafs）の仕様案を述べました。 最小抽象ファイルシステムの仕様案 最小抽象ファイルシステムの仕様案 その2 最小抽象ファイルシステムの仕様案 その3 なんでこんなことを考えたのかを書いてみます。 コンピュータに直接付いているローカルディスクだけではなく、LAN内のファイルサーバーやネットワーク型ストレージデバイスもファイルシステムとして使えます。インターネットでも、WebDAVのようなプロトコルでリモートストレージをファイルシステムのように使えます。最近では、プレーンなHTTPだけで使えるストレージサービスもあります。 そういう状況ですから、「ローカルか、リモートか」とか、「ストレージの実体が何であるか」とかを気にせずに使えるファイルシステムAPIがあったら便利だろうと思ったわけです。特に、HTTP通信を
最小抽象ファイルシステムの仕様案 その3 - 檜山正幸のキマイラ飼育記 (はてなBlog)
最小抽象ファイルシステムの仕様案 最小抽象ファイルシステムの仕様案 その2 これらの続きです。 内容： ファイル名、だいたいのところ アクション設計の方針 エンティティの分類 アクション動詞の分類 API関数のネーミング API関数群の仕様 まだ続く ファイル名、だいたいのところ ファイル名に関しては： ちゃんと考えると、ものすごくめんどくさいですよね。なので、今は決めないことにします。 もう少し決めておくことにします。まず、名前文字という概念に関して次の規約をします。 文字番号32未満の文字は名前文字ではない。 '/'（スラッシュ）, '\'（バックスラッシュ）, ':'（コロン）は名前文字ではない。 他に禁止する文字があってもいいが、それは環境に依存する。 これじゃ曖昧な点が残ってますが、名前文字がなんであるかが確定すれば、次のBNFで「名前」という構文要素を定義できます。 名前 ::
最小抽象ファイルシステムの仕様案 その2 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「最小抽象ファイルシステムの仕様案」の続きです。 さて、具体的な例外の種類ですが、POSIXのerrnoを拝借すればいいんじゃないでしょうか。 あーそれと、HTTPステータスコード（例えば、http://www.studyinghttp.net/status_code）も考慮したほうがいいかも。 と、例外／エラーに関する取り決めについて考えます。 POSIXのエラー番号とHTTPステータスコード Erlangのマニュアル（http://www.erlang.org/doc/man/file.html）に列挙されているPOSIXのエラー番号は32個あるのだけど、そのなかから使いそうな17個を選んでみました。 eacces - permission denied eagain - resource temporarily unavailable ebusy - file busy (リソースが
最小抽象ファイルシステムの仕様案 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「新ユニット結成のお知らせ + GAE上でファイルシステムの模倣」にて： 既存のファイルシステムもどきの仕様は考慮したほうが良さそうだけど、僕の要求としては、非常に素朴な（誰でもが常識と直感として持っている）ファイルシステムのメンタルモデルを表現できることかな。 めんどくさいので既存仕様の調査はしないで腹案を提示します。これから述べるファイルシステムの名前は、mafs (minimum abstract filesystem) です。mafsはプログラミング言語中立です。 とりあえず思ったまま／考えたままを以下に。 内容： 認証と認可 バイナリデータ IOモデル ロッキング ファイル名 カレントディレクトリ オーナーとパーミッション ユニークID、ハードリンク、シンボリックリンク 属性またはメタデータ ディレクトリ ファイルとディレクトリの扱い 例外（エラー） オプションや曖昧性は絞ろう
InfoQ: RESTfulなアプリケーションを記述する
しかしながら、上述のRoy Fieldingの言葉を言い換えると、このようなアプローチはRESTの基本的な原則の一部と相反します。たとえ私たちがこの異議を無視するとしても、 HTTP上に分散型アプリケーションをRESTfullに構築しようとしている人たちには、根本的な問題が残ります。契約を形式的に定義することなくサーバーからの取得はどうするのでしょうか？契約なしでクライアントとサーバーが正しく実装しているということをどのように確かめるのか、それぞれの設計仕様書だけでなく、その他、適切なビジネス/技術ポリシーはどうするのでしょうか？ アプリケーションプロトコルとしてHTTPを使用し、RESTfullな構築をしている分散型アプリケーションには、同じような性質と種類の契約があります。私たちは、何を探し、どこを探すかを知る必要があります。同じ方向にしたがい、私たちが記述言語に向かうならば、それはW
RESTクライアントが知っているべきこと - 岩本隆史の日記帳（アーカイブ）
クライアントとサーバの密結合を避けられるのが、RESTスタイルに従って得られるメリットのひとつです。クライアントが、アプリケーションの挙動に関する知識をほとんど持たなくてよいわけです。 とはいっても、まったく何も知らないではクライアントたりえません。では、何を知っていればよいのでしょうか。 知っているべき4点 その答えは、Roy T. Fielding による記事「REST APIs must be hypertext-driven」で、すでに示されています。下記の4つです。 通信プロトコル（communication protocol） 初期URI（initial URI） メディアタイプ（media types） リンク関係（link relations） AtomPubを例にとると分かりやすいでしょう。 通信プロトコル＝HTTP 初期URI＝サービス文書のURI メディアタイプ＝「a
私が RESTful API の後方互換性を気にするケース - 岩本隆史の日記帳（アーカイブ）
前回の記事「RESTクライアントが知っているべきこと」に、id:nsiena さんからトラックバックをいただきました。 RESTful API の後方互換性 - Siena.の日記 斜め上の応答になってしまうかもしれませんが、思ったことを書いてみます。 API変更の性格分類とサーバがとりうる対策 まず、APIがどのように変更されるか分類し、サーバが取りうる対策をまとめてみましょう。 API変更の性格 サーバがとりうる対策（概要のみ） リソースのURIが変わる ステータスコードで「301 Moved Permanently」を返し、Locationヘッダで新規URIを返す。 リソースのメディアタイプが変わる Content-Typeヘッダで適切なメディアタイプを返す。リクエストのAcceptヘッダによっては、ステータスコードで「406 Not Acceptable」を返さなければならないかも
RESTful APIを用意した地理情報システム、日立ソフト
日立ソフトウェアエンジニアリングは2月16日、各機能をコンポーネント化して提供する地理情報システム（GIS）「GeoMation Remix」を4月1日に発売すると発表した。電力、ガスなどの公共事業で使われている同社の大規模事業者向けGIS「GeoMation」をベースに開発した製品で、日立ソフトは「簡易でスピーディなシステム開発ができる」と話している。 コンポーネント化して提供するのは基本的な地図表示とユーザーインターフェイスのほか、作図機能、属性検索機能、外部データ連携機能など。必要なコンポーネントだけを購入するスモールスタートが可能としている。営業支援システムやCRMへの組み込みなどを想定している。 システムやアプリケーションに組み込みやすいようにカスタマイズも容易にしてある。UIの変更はXMLファイルを編集するだけで可能。コーディングを行わずに基本的なカスタマイズができる。また、シ
JSONPだとエラーがキャッチできない - blog::konk303
これみんなどうしてるのかな？ググってもちゃんとした情報見つけられなかった。 jQuery.getJSONが、シームレスにクロスドメインなJSONPに対応してて超便利、と思って使ってたら、errorのコールバックが動いてなかった。 http://zip.ricollab.jp/のapiがよく出来てて、存在しない郵便番号をgetしようとするとstatus404でcontentにメッセージを返してくれるんだけど、そのメッセージが全然取れない。 なんでやねんと思って良く考えてみたら、JSONPってXMLHttpRequestじゃなくてscriptタグ経由での読み込みだから、onreadystatechangeイベントなんか当然なくて、「通信に失敗」「通信はコンプリートだけどエラー」って状態を取りようがないんですね。 404の時はcontentも捨てられてれるっぽくて（まぁ当然だと思う）、コールバッ
Contacts API Migration Guide | People API | Google for Developers
Contacts API Migration Guide Stay organized with collections Save and categorize content based on your preferences. The Contacts API was turned down on January 19, 2022. Use this guide to learn about changes to fields, endpoints, and authorization scopes as you migrate to the People API. Overview The People API has the same functionality as the legacy Contacts API for all features, with the follow
OpenAuth, Google GData API JavaScript とプライベートデータのクライアントサイドマッシュアップについて - snippets from shinichitomita’s journal
なんかいろいろと書きたくなってきたので書きます。長文失礼。 AOL OpenAuth のように、iframe でメールアドレスを選択させて、その結果を親フレームに返すようにすべきだと思いました 上の続き - kazuhoのメモ置き場 なるほど。クライアント側でのマッシュアップで Service Provider → Consumer の流れなら IFRAME + HTTP Referfer を使った方が軽いということですね。 OpenAuth の仕組みは全然追っていなかったので、 id:shinichitomita さんのエントリをもう一度読んで勉強します。まず、そこから把握しないと議論にもならなそうですね。 クロスドメインのセキュリティ問題を OAuth で解決する, OAuth のアイデアに kazuho さんからツッコミをいただいた, それ OpenAuth で (ry - まちゅダ
Javaと中二病 - 世界線航跡蔵
java.lang.だのjava.io.みたいな古いAPIは「これからオブジェクト指向な新しい世界が始まる」と気負いすぎている割にマーカーインターフェースとか痛々しいことをやっていたりする。その辺は『 Effective Java 』で、中の人自身が「あちゃー。いたた」と反省を述べている。というわけで、この本はJavaのAPI設計における良書でもあるわけだ。 この痛々しいAPIを「 中二病 的インターフェース」と呼ぶならば、その後に台頭した"えんたーぷらいず"な重厚長大APIはさしずめ「 高二病 的インターフェース」だろうか。 昨今のSeasarの活動で成し遂げられ、また羽生さんが「これからようやくJavaが始まる」と言っているのはこのような多重に痛々しい過去を受け入れ、乗り越えてJavaが成人するということなのかもしれない。でも、乗り越えそこなうと「 大二病 」への道なので気をつけよう。
はてなお気に入りAPIとは はてなの人気・最新記事を集めました - はてな
このページは古い情報を掲載しています このページの情報は更新されていません。新しい情報は「はてなお気に入りAPI - Hatena Developer Center」に移転しました。 はてなお気に入りAPIは、あるユーザーが気になっている「お気に入り」ユーザーの一覧を取得できるAPIです。「気になっている」かどうかは、はてな内でのコメントをつける、スターをつける、同じグループに所属するといった行動から算出しています。 お気に入りAPIのURIは以下のようになっています。 http://www.hatena.ne.jp/[ユーザー名]/favorites.jsonたとえば「しなもん日記」の作者id:hatenacinnamonの場合は以下のようになります。 http://www.hatena.ne.jp/hatenacinnamon/favorites.jsonデータはJSON形式で取得でき
ALPSLABの各機能を外部から利用可能な「ALPSLAB api」を公開
ALPSLABではインターネット関連の技術者向けに同サイトが提供している各サービスのAPI（Application Programming Interface）の仕様を公開します。 このAPI公開により、外部の技術者の皆様がALPSLABのコンテンツデータベースや、ALPSLABで提供されている機能を活用し、 自由にWEBサービスやサイトの開発が可能になります。 API公開第一弾として「ALPSLAB コンテンツ検索 API」、「ALPSLAB print API」、「標高取得 API」の３つのAPIを公開します。 ALPSLABコンテンツ検索API 『ALPSLAB』のサービスに投稿された位置情報付きの様々なコンテンツ（ブログ、写真、Webサイト、ルート、ビデオなど）を検索しXML形式で取得することができます。 ALPSLAB print API 『ALPSLAB』サービスのひとつ
第6回 WebAPI、認証APIのセキュリティ | gihyo.jp
WebAPIの公開 APIとは、何らかの機能を提供するプログラムのことです。WebAPIとは、Webで提供されたAPIということです。たとえば、地図データを提供するAPIや商品の検索結果を提供するAPIが有名です。なるべく多くの人にアクセスしてほしい情報を持っている企業は、WebAPIとして情報を提供することが多くなりました。WebAPIという便利なインターフェースを用意することで多くのユーザにアクセスしてもらい、広告ビジネス等につなげていくのが狙いです。 またWebAPIは、多くの形式に対応していたほうが、多くのユーザに利用してもらうことができるため、なるべく多くの出力形式に対応しようとする傾向があります。以前はSOAPという形式が多く使われていましたが、実装方法が煩雑であったため、現在ではREST、JSON、JSONPのように実装がシンプルな形式のものが多く使われています。 WebAP
Inside Tokyo Cabinet その参 - mixi engineer blog
この連載のように小難しい記事が続くと、読者の皆さんだけでなく執筆陣まで引いてしまうのではないかと心配しているmikioです。いやいや、いいんです。ハッキングから夜のオカズまでバラエティに富んだブログを目指すべく、私は私なりの記事を、たとえマイノリティ向けだとしても臆さず書いてゆくのです。今回はTCの実装の詳細についてお届けします。 QDBMとどう違うの? QDBMもTCと同様にDBMの一実装で、小さくて速くて使いやすいをモットーに作りはじめて、それなりに目標を達成できたと自負しているプロダクトです。しかし、今思えばいろいろと気に入らない点がいくつかありました。TCはそれを克服すべく一から書き直したものです。具体的には以下の点が違います。 空間効率の向上 : データベースファイルのサイズがもっと小さい 時間効率の向上 : 読み書きにかかる時間がもっと短い 耐障害性の向上 : データベースファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://googledataapis.blogspot.com/2008/04/google-data-apis-patent-license.html
usingapi.com is available for purchase - Sedo.com
http://www.dehora.net/journal/2007/12/16/amazon-simpledb-non-rest-api/