RESTに関する３つの間違い
楽観的排他制御を利用する非同期的なトランザクション実行であればスケーラビリティを損ねることなく2phase commitが可能である。これは、分散KVSにおけるスケーラビリティと一貫性の両立について で主張したように、同期的な2phase commitは密結合に誘導することになるため、矛盾するように思えるかもしれない。だがそんなことはない。 前半はまずこの話から入るが、後半ではRESTに関する間違いについて、３つほど思うところを述べたい。 楽観的排他制御と2phase commit reflexworksではFeedやEntry単位でatomicなトランザクション処理を行えるが2phase commitはサポートしていない。これを許すと密結合になってスケールしないからである。だが、これはあくまで同期的な処理の話であって、ネットワーク障害への耐性を考慮され、非同期処理やオフラインで使えるので
URLに関する議論 -- なぜ僕はクエリパラメータを擁護、ときに推奨するのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
一時期（2010年の1月頃）、URLの議論をしていて、僕は拡張子を含むURLやクエリパラメータを擁護していました。 そろそろ決着、HTTPメソッド、URL、そして標準化された動詞 RESTfulなWebサイトと拡張子を含むURLについて 最近、またURLの問題を考えてみたのですが、僕が拘っているのは次の2点なのだと気付きました。 すべてのURLを列挙したい。 すべてのURLを分類したい。 すべてのURLを列挙したい あるWebサイトやWebアプリケーション（以下、総称してWebシステム）を考えたとき、有効なURLを完全に列挙したいのです。ここでの「URL」は、正確に言えばクエリパラメータを含まないパス部分のことです。もちろん、有効なURLは時々刻々と変化します。でも、ある一時点を取れば、その時点におけるURLは確定するはずです。各時点ごとのURLの集合を100%把握したいのです。 列挙する
Railsの誤解：CRUDはRESTじゃない！ - 杉風呂2.0 - A Lifelog -
以下はNick Sutterer氏が2010年10月28日に自身のブログに投稿した、"Rails Misapprehensions: CRUD is not REST! "の翻訳です。本人の許可を得て掲載します。 Rails Misapprehensions: CRUD is not REST! http://nicksda.apotomo.de/2010/10/rails-misapprehensions-crud-is-not-rest/ RailsとRESTについて調べている間、二つのことがよくわかった。 RailsでRESTがどうなっているのか、他と比べて、明解で、基礎的で、「印刷された」解説を見つけにくい。数千のスクリーンキャストを見てきたが、この素晴らしいガイドが一つあるだけだった。 みんなCRUDとRESTを混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると
RailsのURL設計を考えてみる(6) 設計の選択肢 - ぶろぐ。@はてな
今回は直接Railsとは関係ないのですが、先日こういうページを見つけました。 http://redrata.com/restful-uri-design/ これは2009年に書かれたもののようですが、URL設計に関する重要な考え方がいろいろ書かれています。 その中に、このブログのシリーズの(4) スラッシュと「持っている」関係や(5) Railsのリソースパターンの前段階になるような“Choosing a URI schemes for resource hierarchies”という話があったので、かいつまんで紹介したいと思います。 リソースの階層に対して、どういうURLを設計するか？ 前提として、設計するWebサイトには、conversation（会話）というリソースが複数あり、それぞれのリソースはユニークなIDで区別されるとします。（IDは数字とは限らない識別子） /conversa
NoSQL は REST に影響を与えるか？
原文(投稿日：2011/10/16)へのリンク 私たちは過去数年間にわたって，従来のデータベース技術の代替となる，いわゆる NoSQL をめぐる議論が日増しに高まっていくのを目の当たりにしてきた。高性能トランザクションに関するワークショップでも，あるいはこの InfoSQL でも，NoSQL は今や REST や SOA などと同じように無視しがたい存在となっている。2009年の議論や，さらに以前の 2007 年に Postgres と Ingres のオリジナル開発者のひとりである Mike Stonebraker 氏による RDBMS 終焉の予想に見られるように，初期の議論は従来の RDBMS を NoSQL 実装で置き換えることを目指していた。しかし Twitter や Amazon といった REST ベース の企業が NoSQL の強力な擁護者となるにつれ，REST と NoSQ
JavaによるRESTfulシステム構築 - yojikのlog
最近、自分が翻訳作業に携わらせてもらったプログラミングScalaという本が出版されました。しかし、自分達の本の宣伝をする前に今まで献本頂いた本の書評をブログに載せるのが筋だろう! というわけでこの本の書評を書きます。 JavaによるRESTfulシステム構築 作者: Bill Burke,arton,菅野良二出版社/メーカー: オライリージャパン発売日: 2010/08/23メディア: 大型本購入: 28人 クリック: 780回この商品を含むブログ (35件) を見る 本書は、監訳者のartonさんの説明を見れば分かるとおり、エンタープライジーな分散システムを構築するためのREST(というよりもJaxRS仕様/実装)という観点で書かれた本です。 JaxRSは、URLとリソース(を表現するクラスやJavaメソッド)、HTTPメソッドとJavaメソッドをアノテーションによりマッピングする機能を
URL Design — Warpspire
December 28, 2010 URL Design You should take time to design your URL structure. If there’s one thing I hope you remember after reading this article it’s to take time to design your URL structure. Don’t leave it up to your framework. Don’t leave it up to chance. Think about it and craft an experience. URL Design is a complex subject. I can’t say there are any “right” solutions — it’s much like the
最近のRESTの進化。バージョン番号、状況報告、プロダクトとしてのAPI
RESTの時代がやってくるのだ、という記事を1つ前の「時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了」で紹介しましたが、そのRESTも使われ方が進化してきているのだ、ということを、その記事の中でとりあげたProgrammableWebのJohn Musser氏が公開しているの資料の中で解説しています。 3つ紹介しましょう。 バージョン番号の組み込み 最近のREST APIにはバージョン番号がURIに埋め込まれるようになったとのこと。 利用者に状況報告 レイテンシーがどうなっていて、正常稼働しているかどうかといった報告を利用者に対してきめこまかく報告するようになったと。APIに依存した外部サービスが増えたためでしょうね。
Whatfettle - Paul Downey (psd)
At the XML Summer School, my marra Marc Hadley and I ran a short workshop on designing REST Webby services. We used pin-boards around the room, along with index cards: which we connected with ribbon to paper-prototype HTTP message flows: People seemed to like the cards, adopting them as labels: All was going well until someone slipped "204 - No Content" into my badge holder. This made me grumpy, b
エンタープライジーなREST - L'eclat des jours(2010-08-10)
_ エンタープライジーなREST オライリーから私が監訳（という作業を初めて経験したわけですが、それは別の物語）した、『JavaによるRESTfulシステム構築』という本が近々出ます。 JavaによるRESTfulシステム構築(Bill Burke) この本は、実にいろいろな面からおもしろい。おもしろいので、オライリーの編集の方に翻訳して出版する価値もあれば意義もあるとお勧めしたわけで、当然、読むことをお勧めします。 さて、何がおもしろいのか。一端は後書きに書いたけど、当然、書ききれない点や後書きに書いてもしょうがない点とかは省略しているので、そのあたりを含めて紹介します。 1. 著者がBill Burke これはおもしろい。というのは、BillはJBoss野郎なのだ。当然、CORBAからのORPC男。当然EJB。もちろんEJB3。 なぜ、そのBillが『JavaによるRESTfulシステ
RESTfulな設計とCRUDはちょっと相性悪いという話 - yojikのlog
http://www.infoq.com/jp/news/2009/08/CRUDREST 上記URLを読んで自分なりに例題を考えてみる。(todo:あとで状態遷移図を追加) RestBucks cafe 完全にオンライン化されていてWebAPIで注文できるというすごいカフェを想定します。(この手の例にStarbucksを使うのはGregor Hopeさん以来の伝統らしいです) 客側から見たユースケースはこんな感じ 客はレジのサービスを呼び出して、注文を入力して支払い 自席で注文状況をチェック、出来上がっていたら取りに行く。 注文というエンティティと、[注文編集] [支払い] [受け取り] という(アプリケーション)状態によって上手く表現できそうです。 (RESTfulだけど)CRUDな設計 CURDな設計では、リソースをURLにマッピングします。それに対してCRUDするというイメージです
Webサービスの設計： ハイパーオブジェクトはワークフローやインターフェースも運ぶ - 檜山正幸のキマイラ飼育記 (はてなBlog)
「Webサービスの設計： ハイパーオブジェクトとトリガー」において： 僕は「Webとはハイパーリンクなり」と考えているので、Web APIでもなんでもハイパーリンクを使ってないなら「Webっぽい」とは思いません。RPC（遠隔手続き呼び出し）的な要素を取り入れても、ハイパーリンクを活用しているならWebっぽいでしょう。「っぽい」とか「らしい」は単なる趣味嗜好の問題ではなくて、ハイパーリンクの活用は大きなメリットがあります（そのメリットの説明は今日[注：2010年8月11日]はしませんが）。 「ハイパーリンク活用の大きなメリット」について、今日（2010年8月25日）は説明します。 内容： 遠隔呼び出しとHTTP インターフェースと手順の合意 あなたに任せるわ、私は言われるまま 理想のケースは人間がクライアントのとき 状態遷移モジュール インターネット／Webの驚嘆すべき頑健性 遠隔呼び出しと
信頼できるメッセージングは、不要。
原文(投稿日：2010/06/18)へのリンク SOA やWeb サービスで一般的に容認された考え方は、信頼できるメッセージングの必要性である。信頼性のあるメッセージングとは、送信アプリケーションによって送られたメッセージは、もう一方で確かに、受信されそして１回のみ受信される、ことを保証する。RESTに対する最も共通の拒絶理由の１つは、RESTが信頼できるメッセージングを提供していないことである。Stefan Tilkov 氏が次のように書いている：「RESTful HTTPは、WS-ReliableMessaging と同等ではない、としばしば指摘され、このために、信頼性が争点（これは、相当変わってしまう。あらゆるシステムがビジネス シナリオによって、どのような関連性でも持つので）となる分野では、使えない、と多くの人々が結論している」[1]。もちろん、Tilkov氏は、これに賛成しないで
RESTなリソースへリクエストを送りたい - ちくわプログラマにっき
NSMutableRequest#setHTTPMethod:でGET/POST/PUT/DELETEを指定することでRESTなリソースに対してのリクエストを送信することができる。 POSTとPUTの時には送信するコンテンツのContent-Typeを指定することを忘れずに。(今回はXMLデータを送信するのでapplication/xmlを指定している) // POST { NSURL *url = [NSURL URLWithString:@"http://example.com/users.xml"]; NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url]; [request setValue:@"application/xml"forHTTPHeaderField:@"Content-Type"
RedmineのRESTful APIを使う - プログラマの思索
RedmineのtrunkにはRESTful APIが公開されている。 アイデアをメモ。 【元ネタ】 Twitter / yusuke-kokubo: RedmineはREST APIを持ったことで色んなやりたいことができるようになる。 Redmine - Rest api - Redmine Redmineをプロジェクト管理サーバーとして扱うならば、他のツールや機能と連携したくなる。 その時にRESTful APIはとても便利。 大量のチケットを一括インポートするためのデスクトップアプリを作りたい。 MSProjectのタスクをインポートしたり、逆にMSProjectに取り込んだりしたい。 HinemosやTivoliのようなサーバー監視ツールが障害や警告を検知したら、すぐにRedmineチケットを発行して、障害やインシデントのその後の経過も管理したい。 TestLinkやHudsonな
内海 英一郎のブログ: REST の複雑性？
Web 上に展開されたサービスのいくつかは、ユーザーとのインタラクションを行う HTML ドキュメント ページ以外に、開発者向けに API を提供しています。これらは、直感的な URI と HTTP ベースのシンプルな方法でアクセスすることができ、RESTful Web サービス API と呼ばれています。僕も REST ファンの一人で、RESTafarians とまではいきませんが、WWW の生態系を支えるシンプルなスタイルをとても気に入っています。 REST (Representational State Transfer) アーキテクチャー スタイルについての概要は、Roy Fielding 氏による論文 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm または、山本陽平さんのブログ http
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
When to use query parameters versus matrix parameters?
#350 REST API Versioning - RailsCasts
GitHub - RestExpress/RestExpress: Minimalist Java framework for rapidly creating scalable, containerless, RESTful microservices. Ship a production-quality, headless, RESTful API in the shortest time possible. Uses Netty for HTTP, Jackson for JSON, Metrics
RESTをサポートしているという Webフレームワークは、どの程度 RESTful か？
