CRUD型RESTの欠点と、読み取り可能なURI - winplusの日記
「CRUD型RESTの欠点」として挙げられている以下の点。 外部に見せているのは内部的なデータベース構造ないしデータであって、考え抜かれた契約ではありません。 本当のサービスを迂回して直接データにアクセスすることを助長します。 CRUDはRESTにとって良くないのか？ テーブルを知らないとSQLは使えない訳で、それをそのままマッピングするのはテーブルを公開しているのと同じ。これを利用するには、クライアント側が、すべてのビジネスロジックを把握する必要がある。 羊の皮をかぶったクライアント−サーバでしかありません。 CRUDはRESTにとって良くないのか？ 確かにね。 ちゃんとしたRESTfulなWebサービスであれば、クライアント側は一切のビジネスロジックを把握する必要がなくなると。そうであれば、必要かつ十分なWebサービスは、すべてハイパーリンクで提供される。つまり、クライアントがハイパー
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 この
RESTful or not - Logical and Creative i18n
今日はRESTfulについてのお話。 RESTとはRepresentational State Transferの略称で、ウェブサービスのインターフェースとしての分かりやすい設計の新しい手段として使われ始めている技術です。 RESTfulなウェブサービスの具体的な実装の4つの基本原則が HTTPメソッド(POSTとかGETとか)を明示的に使う ステートレスにする URIをディレクトリに似た階層構造にする XML,JSONのいずれか,または両方を転送する となっています。 では実際に現在主に使われているやり方とRESTfulなウェブサービスとの違いを考えてみます。 というか自分で理解した中で疑問も合わせて書いてみます。 1.HTTPメソッドをCRUDモデルに当てはめて,ディレクトリ構造のURIと対応させる 現状は特に意識せずにファイル名をそのままURIにしたり、mod_rewriteを使って
What's allowed in a URI?
Java 1.4 introduced the java.net.URI which provides RFC 2936-compliant URI handling. I thought I should try to fix Jing and Trang to use this. So I've been looking through all the relevant specs to figure out to what extent I can leave things to java.net.URI. It's convenient to begin with XLink. Section 5.4 requires the value of the href attribute to be a URI reference after certain characters th
URL 正規化 - KBDAHOLIC - やぬすさんとこ
hatebuize 作るときに google と yahoo で出てくる URL が違うことに気づいてムキーってなって手動で yahoo の URL を google っぽくしてたんだけどそういえば direct_bookmark.js ( http://unsigned.g.hatena.ne.jp/Trapezoid/20080411/1207842257 ) でなんか URL 正規化とかいう関数あったなと思い出してみてみたら pathtraq の URL 正規化 API ( http://pathtraq.com/developer/#help_normalize_url ) 使ってたのでそれで URL 正規化ってなんだろうと思って調べてみた。 最初はサイト立ち上げる際に RFC ( http://www.ietf.org/rfc/rfc1738.txt ) に沿った形にするってこと
リソース指向の URI 設計に悩む
『RESTful Webサービス』読んでんですよ。まぁあらかた読んだんです。いちばん気になっているのはリソースの設計の部分なんですが、これを URI にマップするときにどうにもうまくいかないものが出てきて、しかもまだ解消していないので、それを書こうと思います。（実際のコードのレベルでは「えいや」でルールを決めてしまいましたが。） 何が問題かというと、 順番も有無も任意に決められ、かつお互いに階層関係にないパラメータで決定されるリソースの URI へのマップです。 例えば書籍の中では、2値によって決まるリソースとして緯度、経度が出てきますが、このときはカンマで区切ることで一つの位置という情報を表現していました。（typo で ; になっているところが何カ所もありますが、カンマになっていないと意味が通じません。） このパターンは 「緯度経度」の順番緯度、経度ともに欠けることがないであり、比較的
Algorithmic Resource - てきとうなメモ
RestfulなURIの設計として以下のようなことがよく言われているような気がするのだが URIは名詞にすべき クエリ文字列(?foo=barの部分)は使うべきではない あんまりこだわるべきではないなと思った． 例えば検索結果などがそうだと思うんだけども，最近リリースされたYahoo Boss APIなどは Hostname Basic Example http://boss.yahooapis.com/ysearch/web/v1/dvd Yahoo! - 404 Not Found のようなURIになっている．あとニコ動のURIとかも． こういうURIは意味が分からない訳ではなく，悪いとまでは思わないのだが，検索結果を指しているのにdvdという1つのリソースを指しているっぽく見えてなんだか違和感がある． 普通に http://api.example.com/search?q=dvdと書
URI::Platonic というモジュールを書いた - 烏賊様
プラトニック形式の URI という呼び方は RESTful Web サービスに出てきて初めて呼び方を知ったんだけど，そのプラトニック形式の URI と，拡張子付きでリソースの詳細な表現形態を指定した URI（長いな…）をもっと簡単に扱いたかったので，そんなモジュールを書いてみた． http://coderepos.org/share/browser/lang/perl/URI-Platonic use URI; use URI::Platonic; my $uri = URI->new("http://example.com/path/to/resource.html"); $uri->platonize; # "http://example.com/path/to/resource" (URI object) $uri->platonic_path; # "/path/to/resour
.aspx considered harmful
It’s been a decade since Tim Berners-Lee wrote Hypertext Style: Cool URIs don’t change, the first contribution to what is still not a very extensive literature on designing namespaces for the web. Recently, when I made the suggestion that a blog engine ought not produce URLs that end with .aspx, I was asked: “Why does it matter?” For me it boils down to two reasons: Futureproofing A blog posting i
URLをアクセスしやすくする
この記事は最初にIBM developerWorksで公開されました。 実用的な命名体系で初心者とエキスパート・ユーザを満足させてください Peter Seebach(crankyuser@seebs.plethora.net) 2001年6月 多くの、特にオーサリング・ツールで作成されたWebページが、 URLを理解不能なマジック・クッキーとして取り扱う傾向があります。 URLが読みやすく理解可能で、URLの構造がサイトの構造を反映しているとユーザの役に立ちます。 世間知らずのユーザさえもこのようなデザインに救われるかもしれません。 ここで、PeterはURLを理解しやすくすることがなぜ重要であるか調べ、 そしてこれを効果的に実行する若干の戦略を提供します。 ユーザー志向 vs エキスパート志向 人々が通常URLを無視する理由の１つはそれらが好ましいインターフェース
yohei-y:weblog: REST 入門(その8) REST でないもの
» REST 入門 目次 WWW は REST アーキテクチャスタイルのアーキテクチャを採用した実装のひとつですが、 REST アーキテクチャスタイルでないアーキテクチャの WWW アプリケーションもかなり存在します。 REST でないものを一言で言ってしまうと、 URI と HTTP を正しく使っていないもの、ということになります。 以下では URI と HTTP の誤った使い方について説明します。 URI をクライアントで組み立てる URI をクライアント側でごちょごちょ組み立てなければならないのなら、それは REST ではありません。 たとえば、はてなブックマーク AtomAPI が、こんなインターフェースだったらどうでしょう? ブックマークをキーワードで検索する。 POST /uso/bookmarkSearchService HTTP/1.1 Host: b.hatena.ne.
CRUDのうた - 世界線航跡蔵
解かった。解かった。解かったぞ。 それはCRUDだ。すべてがCRUDだ。CRUD、CRUD、CRUD。 HE does create it. HE does refer it. HE does update it. HE does destroy it. Every valley, every valley shall be exaaaaaaaaaaaaaalted, shall be exa-lted. shall be exalted, shall be exaaaaaaaaalted and every mountain and hill be made low, と、叫びながらHallelujahとばかりに走り出したい気分だったけれどさすがにそれははばかられたので、心の中で"Messiah"を流しながら何食わぬ顔で電車に乗ってきた。多分ABDとかCRUDとかRESTful URIと
Cool URIs for the Semantic Web
Cool URIs for the Semantic Web W3C Interest Group Note 03 December 2008 This version: http://www.w3.org/TR/2008/NOTE-cooluris-20081203/ Latest version: http://www.w3.org/TR/cooluris/ Previous version: http://www.w3.org/TR/2008/NOTE-cooluris-20080331/ Editors: Leo Sauermann (DFKI GmbH) Richard Cyganiak (DERI, NUI Galway and Freie Universität Berlin) Contributors: Danny Ayers (Talis Information Ltd.
馬鹿につける薬: 実際に設計してみよう その3
さて、前回で、RESTというスタイルで考えた場合、既存のシステムとは異なるURL体系になることがわかった。 これは何もおかしなことではなく、既存のwebアプリではアプリケーション（というよりもインターフェースか？）が前面に出ており、実際に操作したいリソースはDBという形で見えなくなっており、RESTではそれを覆して、リソースを前面に押し出し、アプリケーション（インターフェース）をプロトコルの中に格納したからだろう。 というわけで、URLについてもう少し考えてみることにする。 まずは先送りにした検索について考えてみようと思う。 会議室予約システムを考えた場合、検索したいのは「空いている会議室」だけだろう。 そこで、空いている会議室を検索する方法（URL）についてのみ考えてみる。 まず、既存のシステムだとどのようになるだろうか？ 多分こんな感じになるんじゃないだろうか？ http://intr
リソースが3段以上ネストしたときのmap.resourcesの書き方
RESTfulなサービスを実装するとして、対象リソースがその他のリソースとの従属（親子）関係があるときに、Ruby on Railsではmap.resourcesをネストして記述することが可能になっている。例えば、部署(Division)に所属する社員(Employee)のリソース定義であれば、 map.resources :divisions, :path_prefix => ‘/api’ do |divisions| divisions.resources :employees, :controller => ‘api/employees’ end とすることで、「GET http://localhost:3000/api/divisions/1/employees/2」というURLにApi::EmployeesControllerクラスをマッピングすることができる。この場合、show
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20080708/p01/
Why SnipURL’s API is Unsafe a.k.a. How NOT to design your Web API | Blog for The Well Designed URLs Initiative
http://www.kurano.jp/blog/sadayuki/articles/2008/01/12/uri%E3%81%AF%E5%81%89%E5%A4%A7%E3%81%A0%EF%BC%81
Addressable
https://www.ietf.org/internet-drafts/draft-wilde-text-fragment-09.txt