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に実装するか - 岩本隆史の日記帳（アーカイブ）
「コマンド的な処理をどうやってRESTfulに実装するか」に書いた内容を敷衍します。 SunのクラウドサービスAPI 先日、Sun MicrosystemsがSun Cloudというクラウドサービスを提供すると発表しました。 米Sun、Amazon対抗のクラウドサービス「Sun Cloud」を発表 - SourceForge.JP Magazine この記事には、クラウド操作用APIがRESTベースで提供される予定であることも書かれています。 Sunは開発者向けにクラウドAPI「Sun Open Cloud API」を提供する。RESTベースのAPIで、CreativeCommonsライセンスの下でリリースするため、開発者はSun Cloudと相互運用性のあるクラウドを構築できるという。 そのAPI仕様のドラフトが「The APIs for the Sun Cloud: Wiki: Hom
geo+webの人は皆「RESTful Web サービス」を買うべき - Relevant, Timely, and Accurate
d:id:hfu:20090316 に対するはてなブックマークで、yohei さんにコメントをいただきました。 任意矩形をquery paramsで取得するのはRESTfulに設計できます(RWS第5章)。サーバ内部の処理とインターフェース設計はまずは別に考えるべきと思います。 http://b.hatena.ne.jp/entry/http://d.hatena.ne.jp/hfu/20090316/1237148944 実は、RWS こと「RESTful Web サービス」、昨日入手したところでした。セレンディピティ*1、ですね。早速開いてみています。 RESTful な任意矩形指定 RWSこと「RESTful WEb サービス」5章 p.124 に、次のように書かれています。 http://maps.example.com/geologic/Earth/43.9,-103.46 この
リソース指向なgeo+webのサブクラス - Relevant, Timely, and Accurate
リソース指向なgeo+webのサブクラスの定義を試みます。 convivial-weblog さんから。 RESTfulは、リソース指向的な考えに基づいたアーキテクチャなので、何かしらの処理を関数的に実行させたい場合などは、RPC（Remote Procedure Call）的に呼び出せる「なんちゃってREST」の方が適しているケースも多いように思います。 http://convivial-web.com/blog/2009/03/restrestful.html 関数的に呼び出す形のものはやはり RPC 的にしておくのがよさそうだと思っています。OGC の規格でよくある、引き出し対象を任意の矩形で指定するようなパターンは、典型的に RPC 的なパターンであると考えており、あのパターンを RESTful にすることは至難だと思います。 geo+web の特徴の分析から、そのような RPC
浅葱さんのブログ REST 対 SOAP とかいってみたりするテスト
いやその特段仕事で経験値を積んだわけでもなくなんといいますか技能低下防止にとそこらのＩＴ系ブロガーのＲＳＳ眺めているだけなんですが、地理情報業界でＲＥＳＴ対ＳＯＡＰといった話が出てきて arton さんまで引用しているとはただならないものを感じるのであります。 要するにまだ話題自体よくわからんのだけど、2005年頃OGCがISOと結託してXMLベースのクソ分厚いプロトコル群にまとめ始めたのと同じくらいのエポックみたい。 とりあえず、話にまとめる時間を天が許すとは思えないので、わかったことだけ。 SOAP が勢力を築いてきた地理情報の世界に REST(ful) が勝ちという世間の潮流がなだれこんできたようだ。よくわからんが simple is the best という我が信念からすれば神は偉大なりと唱えるところであろう。 ここ数年欧州ががんばってINSPIREというものをつくっていて、止せば
RESTアンチパターン
多くの人々にとって、RESTは単純にあるアプリケーションの機能を公開するためにHTTPを使用することを意味します。基本的で最も重要なオペレーション (厳密に言えば、「動詞」や「メソッド」がより良い表現です)は、HTTPのGETです。GETはURIによって特定されるリソース表現が必要です。しかし、多くの場合、それがすべてではないとしても、既存のHTTPライブラリやサーバープログラミングAPIは、リソースの識別子としてではなくパラメータをエンコードするための便利な手段として見ることがとても多いです。結果、以下のようなURLとなります。: http://example.com/some-api?method=deleteCustomer&id=1234 実際、URLを作る人は、与えられたシステムの「RESTful具合」について何も言いません。しかし、私たちは特定の場合においてGETが「安全」では
REST vs SOAP
GET /WebSite1/WebService.asmx/getHello?str=string HTTP/1.1 Host: localhost HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <string xmlns="http://tempuri.org/">string</string> RESTは、WebブラウザのAjaxや、クライアントアプリから使う場合もあるが、サーバ間のシステム連携でも使う。 RESTの最大の特徴は「WebブラウザにURLを入力すれば動作確認できる」事である。 Webブラウザで容易に動作確認ができるため、すでに存在しているサービスに対しては「まずはアクセスしてみて必要な情報
yohei-y:weblog: REST ってやっぱり難しいかも。
前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。
ただのにっき (2006-03-01) - おれだったらフォト蔵APIをこうする
■ Apple新製品 iPod Hi-Fi、ダセぇ。これがApple製品だなんて信じらんない。他社製品が間違って紛れ込んだんじゃないのか。 Mac miniは、相変わらずちょっと欲しい。やはり小さい機械には惹かれる。これでWindowsが動けばなぁ(←だいなし)。 ■ おれだったらフォト蔵APIをこうする せっかくユーザでもあるので(携帯のバックアップにしか使ってないけど)、β公開されたフォト蔵API(アナウンス)を使ってみることにした……んだけど、概要を読んで「ちょっと待て」と思った。 フォト蔵APIは全てRESTで提供されています。機能毎の個別のURLに対して必要なデータをPOSTします。結果は全てXMLで返ってきます。 えーと、GETを使うべきAPIでもPOSTですかね。それ、RESTじゃなくてただの「なんちゃってRPC」だし。……とは言ったものの、自分だってRESTを理解しているか
Tender Surrender » OpenSocial/RESTful API Specification
RESTful APIはすべてのOpenSocial 0.8に対応したクライアントおよびサーバーに共通のプロトコルとして提供されます。これは2007年11月に発表されたGDataベースのOpenSocial data APIを置き換えるものです。 概要 † このAPIはクライアントがウェブページ上のガジェット外部にあるOpenSocialコンテナサーバーとやり取りするための、言語にもプラットフォームにも中立なプロトコルを定義します。プロトコルとしては、どんな言語でも、どんなプラットフォームでも比較的容易に実装可能なように作られています。この仕様は、ウェブページ上のガジェットから、ユーザーデータの同期を行うサーバーまで、様々なクライアントから利用することができます。 このプロトコルは主に、リソースとそのオペレーションについて扱い、HTTPプロトコル上でサーバーから取得や更新を行う標準のHTT
yohei-y:weblog: HTTP ステータスコードを正しく使おう
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
http://blog.tkmr.org/tatsuya/show/301-jester-restfull-rails-javascript