Webサービスを設計するための単純明快な方法 - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサイト」、「Webアプリケーション」、「Webサービス」、「Web API」などの用語の区別はそれほど明確でもないし、きっちり区別して使うのもめんどくさいので、ここでは、これらを総称してWebサービスと呼んでしまうことにします。 山本陽平さんは、その著書『Webを支える技術』のなかで、人間がブラウザを使って利用するWebサイトとプログラム向けのWeb APIを区別すべきではないと述べています。この点は僕もまったく同感・同意です。 人間が相手となると、視覚的な効果や装飾、JavaScriptを使った操作性などにフォーカスが向けられ、Web APIとはまったく別物のような印象を与えます。しかし、各ページが持つべき情報やページ遷移の有向グラフ構造などは、相手が人間でもプログラムでも同じだと思うのです。そんな事情で、Webページの機能的／情報的なエッセンスを表現したHTML文書をクリーンH
Richardson Maturity Model
steps toward the glory of REST A model (developed by Leonard Richardson) that breaks down the principal elements of a REST approach into three steps. These introduce resources, http verbs, and hypermedia controls. 18 March 2010 Recently I've been reading drafts of Rest In Practice: a book that a couple of my colleagues have been working on. Their aim is to explain how to use Restful web services t
Flex (Flash Player) で RESTful サービスのクライアントを実装するのは厳しい - tilfin's note 跡地
色々と調べてみたら最終的に八方塞がりに陥りそうです。 Flash Player では GET, POST メソッドしかサポートしていない。 Flash Player では GET メソッドで カスタム HTTP ヘッダを付加することができない。 URLLoader では HTTP ステータスを取れる（但し、一部のブラウザ環境では動かない）とある。しかしこれは IE だけで Firefox, Opera, Safari などは取れず全て 0 になってしまう。（一部というよりほとんどのブラウザかと…） エラー（IOErrorEvent.IO_ERROR）の場合は、data プロパティでレスポンスボディが取ることができない。 IE では前述のとおり、HTTP ステータスを取れるが 201 Created などは IOErrorEvent.IO_ERROR となり 200 OK 以外はエラーとして
RESTとトランザクション？
原文(投稿日：2009/6/15)へのリンク RESTとその他のアプローチ(特にWebサービス)の利点の比較、もしくはもっと単純にRESTをWebベースのインテグレーションで利用する利点に関して、長い間、議論されてきた。議論は続いているが、他の領域では当然と思われていて、REST、特にREST/HTTPに欠けている機能があるのかどうかという点を、一部の人は議論の対象にしようとしている。それらのうちの一つに、分散トランザクションがある。Bill Burke氏がRESTeasyに実装した内容を示し、コメントを求めたことから始まった、REST-discussion メーリングリストでのやりとりがあった。 素晴らしくきれいなAPIです。私はシステムによって公開されるURIの数を減らし、システム全体の柔軟性を高めるために、AtomのLinkで、発行されるURI schemeのいくつかを置き換えられな
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
InfoQ: RESTfulなアプリケーションを記述する
しかしながら、上述のRoy Fieldingの言葉を言い換えると、このようなアプローチはRESTの基本的な原則の一部と相反します。たとえ私たちがこの異議を無視するとしても、 HTTP上に分散型アプリケーションをRESTfullに構築しようとしている人たちには、根本的な問題が残ります。契約を形式的に定義することなくサーバーからの取得はどうするのでしょうか？契約なしでクライアントとサーバーが正しく実装しているということをどのように確かめるのか、それぞれの設計仕様書だけでなく、その他、適切なビジネス/技術ポリシーはどうするのでしょうか？ アプリケーションプロトコルとしてHTTPを使用し、RESTfullな構築をしている分散型アプリケーションには、同じような性質と種類の契約があります。私たちは、何を探し、どこを探すかを知る必要があります。同じ方向にしたがい、私たちが記述言語に向かうならば、それはW
REST信者が激論で分裂の危機？ 「恋愛はGETかPUTか」“べき等”かどうかがカギ - bogusnews
美しいWebサービス設計に欠かせない思想として注目されている「REST（Representational State Transfer）」。HTTPプロトコルに「リソース指向アーキテクチャ」という考え方を導入し、「なんでもRESTで表現できる」として熱心にこの思想の普及につとめている人々は「RESTafarians」＝REST信者として尊敬を集めているが、いま彼らが分裂の危機に瀕している。REST論壇を真っ二つに分ける激論が勃発したのだ。議論の火種となったのは 「恋愛は“GET”で表すべきか、“PUT”で表すべきか」 というもの。 リソースへのアクセスメソッドをGETにするかPUTにするかは、REST信者にとっては美しいWebサービスを設計するうえでもっとも重要な問題だ。ここで「恋愛はGET」と主張して譲らないのが、業界でRESTエヴェンジェリストとして知られる株式会社リコーの山本陽平氏。
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 この
MicroApps - Microapps.org
Buyer Protection Program When you buy a domain name at Dan.com, you’re automatically covered by our unique Buyer Protection Program. Read more about how we keep you safe on our Trust and Security page. Next to our secure domain ownership transfer process, we strictly monitor all transactions. If anything looks weird, we take immediate action. And if the seller doesn't deliver on their part of the
yohei-y:weblog: 半構造データ、あるいは Web 上のデータ
国島先生や斉藤先生が XML や半構造データについていろいろ書いてくださっており、それに反応する形ではてなブックマークや twitter 上での議論が日本語で進んでいて面白い。 http://kunishi.blogspot.com/2008/12/twitter.html http://leoclock.blogspot.com/2008/12/relational-style-xml-query-sigmod-j.html http://kunishi.blogspot.com/2008/12/xml-db.html ブックマークや twitter で細かいコメントを書いているだけでは申し訳ないような気がするので、久々にエントリを書こうとしたのだけれど、なんだかバックグラウンドが長くなってしまった。最先端の研究者のみなさんに失礼な物言いもありますが、XML guy としては XML の
HTTPだけでP2Pシステムを構築できないか？ - Tomo’s HotLine
IT技術を中心に、暮らしに役立つ情報からクラシック音楽の解説まで気軽に情報発信しています。 WEBサイトはhttp://toremoro21.world.coocan.jp/ Twitterは@toremoro21です。 現状大抵のシステムがＨＴＴＰで実現できているので、P2PもＨＴＴＰでかなりの部分構築できないのかな、と考えています。これは先日のエントリーの「Ｐ２Ｐシステムのインターフェース共通化の提案」の発展版です。 まずこの目論見を説明するためにＰ２Ｐを２つのタイプの機能にブレイクダウンします。 ・Ｐ２Ｐクライアント機能 ・Ｐ２Ｐサーバ機能 Ｐ２Ｐなのにクライアント、サーバと名づけるには違和感がある人もいるとは思うが、まずはこれで説明しよう。クライアント、サーバが意味することは後ほど説明します。 Ｐ２Ｐクライアント機能は「ＨＴＴＰクライアント」です。もっと具体的に言うと、ＨＴＴＰでＰ
RESTful Zip Search API Specification -- ricollab
このサービスで提供するリソースは、以下の3種類の表現を持ちます。 XHTML Media Type: application/xhtml+xml; charset=utf-8 標準的な Web ブラウザで表示することのできる形式です。ブラウザで表示させることが可能なので、人間が読みやすいのが特徴です。この表現は整形式の XML であるため、XML パーサーでパースして、プログラムから扱うことも可能です。住所の構造情報は class 属性で表現されています。全てのリソースのデフォルト表現になっています。 この表現は妥当な XHTML 1.1 になるはずですが、あえて DOCTYPE 宣言は付けていません。文字エンコーディングスキームは UTF-8 です。 http://zip.ricollab.jp/1120002 http://zip.ricollab.jp/search?q=大手町 ht
flowr ～ WEB間アプリケーションフレームワーク ～
flowrとは？ ブログや Wiki を使うときに、「使い勝手はこちらのツールが気に入っているんだけど、機能が足りないんだよなあ」とか「ブログサービスにこの機能を追加したいんだけど、勝手にそんなこと出来ないし……」などと思ったことはありませんか？ 他の人が作った Web アプリケーションやサービスの連携や拡張を行ったものの、相手がバージョンアップして仕様が変わってしまったために、作り直さなくてはならなくなったという経験はありませんか？ flowr (フラワー) はそれらの問題を解決しうる方法の一つとして構想している、「外付け可能な Web 間アプリケーションフレームワーク」です。 flowr の仕組み flowr が対象とするのは、パーマネントリンクを持つ Web アプリケーションです。一般的なブログや Wiki、Amazon のような製品情報ページの URL が一定のルールで固定化できる
O'Reilly Japan - RESTful Webサービス
本書は、RESTというWebのアーキテクチャスタイルについて解説する初めての本格的な書籍である。RESTFulなアーキテクチャの概念、RESTfulなサービスの特徴について述べ、RESTful Webサービスを設計するための基本的なルールであるリソース指向アーキテクチャについて解説する。現実のRESTfulなサービス、AmazonのS3、AtomPub、地図アプリケーションなどを例に挙げ、さらに、del.icio.usのAPIなど、RESTの制約を満たしていないが、よく知られているサービスを取り上げ、それらをRESTfulに再設計する方法も紹介する。RESTの概念から実装まで、深い知識が得られる本書はWeb開発者必携の一冊である。 はじめに 1章 プログラマブルWebとWebサービス 1.1 プログラマブルWebの概要 1.2 HTTP：エンベロープに入ったドキュメント 1.3 メソッド情
2007-12-06
洋書で買おうと思ってたけど、翻訳がでるのですね。 http://www.oreilly.co.jp/books/9784873113531/ http://www.meti.go.jp/kohosys/press/0004397/
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web-Oriented Architecture
Gartner Blog Network
InfoQ: CRUDはRESTにとって良くないのか？
http://www.douglaspurdy.com/2009/03/20/murl-a-dsl-for-restful-clients/
http://blogs.sun.com/sandoz/entry/latest_jersey_with_latest_scala