IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
Protocol Buffer の話題は一部で熱く語られた...というより炎上していた. ようやく炎がおさまってきたから, 野次馬として現場にかけつけてみたい. 火事と喧嘩はウェブの華. 火元から見ていこう. 熱心な Google ウォッチャーである MS の Dare Obasanjo が, protobuf 公開に合わせ すかさず "The Revenge of RPC: Google Protocol Buffers and Facebook Thrift" という記事を書いた. 記事の主張自体は穏当なもの. 「最近一部で バイナリエンコードな RPC が流行ってるみたいだけど, 時代は XML と REST で疎結合じゃなかったの？」と修辞的な疑問を示しつつ, "いや基本的に Web は XML で REST な時代なんだけど, Web に出ない会社の内部ならバージョンやらツールを
Permalinkという概念が浸透して、比較的最近作られたようなウェブのサービス上にあるリソースには、そのリソースを一意に表すことのできるURLが割り当てられているようになりました。このブログの記事を表すURLはhttp://labs.gmo.jp/blog/ku/2008/06/fav.htmlで、このURLにアクセスすればこのページがなくなったりしない限りは"多くのサービスに見られるコンテンツに対するfavという概念"について書かれた文章が得られます。このブログにある記事が増えたり減ったりしても、この記事を表すURLは変わりません。 read/write ひとつのリソースに普遍的なひとつのURLが割り当てられていれば、そのURL自体をIDにしてリソースを読み書きすることができます。以前デバイスドライバ/FUSEのrestfs/SITEINFOの役割比較で触れたRESTfsはその前提の上
Atompubの勉強始めました。 Catalyst::Controller::Atompubについて こちらはid:teahut*1さん自身がPerl(Catalyst)でAtompubサーバーを作る解説記事を書かれていますので、そちらを見ると大体分かると思います。 で今の所、分かった事とか困ってる事とか書いてみる事にします。 URLが基本的にpackage名で固定されてしまう。 例えば、コレクションFeedを取得したい場合はコレクションリソースURIに対してGETするんですけど、そのCatalystアクションの書き方は、 sub get_feed :Atompub(list) { # implements } みたいに書くんですが、これが仮にpackage MyApp::Foo::Collectionだとすると/foo/collectionに固定されてしまいます。 と言うのもCataly
第2版（2008年1月19日）：翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。本稿では、本筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
