𝘮𝘢𝘴𝘶𝘪 @masui 「RESTアーキテクチャのおかげでWebは成功した」という表現は正しいのだろうか? 「Webは成功した。Webの特徴はRESTという風に表現できる」ということはないのだろうか? 2010-05-08 23:20:45
RESTが先か、Webが先か
𝘮𝘢𝘴𝘶𝘪 @masui 「RESTアーキテクチャのおかげでWebは成功した」という表現は正しいのだろうか? 「Webは成功した。Webの特徴はRESTという風に表現できる」ということはないのだろうか? 2010-05-08 23:20:45
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
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するというイメージです
OAuthやOpenIDをサポートしたRESTfulデータストア·CloudKit MOONGIFT
エンタープライズ向けのシステムはともかく、個人で作るサービスや自社のWebサービス構築においてクラウドをもっと活用すべきだ。ハードウェア資産やデータベースのメンテナンスなどに頭を悩ますこともなく、作りたいものを作れる環境が得られるようになる。 HTTPを使ってデータをストア、取得する データをストアする仕組みを考える際に、ついデータベースを頼りたくなるが本当にデータベースに入れる必要があるだろうか。並び替えや絞り込みをしないなら、もっと単純なデータストアでも十分なはず。そこで見てみたいのがCloudKitだ。 今回紹介するオープンソース・ソフトウェアはCloudKit、RESTfulなJSONデータストアシステムだ。 CloudKitはRubyで作られたシステムであり、HTTPを使ってデータベースにアクセスする。ストアする際も、取得する際も利用するのはJSON形式だ。スキーマの定義など気に
何がRESTを良くするか？
先ごろRoy Fieldingは、SocialSiteのREST API(リンク)に対して、RESTfulではないと批判した(リンク)。Royは、RESTだと主張するシステムが、多くの場合にRESTから程遠いことの例として、SocialSiteのREST APIを取り上げた。 (OpenSocialのREST API)はRPCです。それはRPCだと叫んでいます。画面のXレートを指定するために、とても多くの結合があります。 Royに同意するための証拠を、OpenSocialのページで見つけるのは(リンク)、それほど難しくない。例えば、 サーバサイドで、OpenSocialスタイルのRESTとJSON-RPCをサポートする クライアントサイドで、リクエストのJSON-RPCバッチ処理をサポートする 拡張のために、OpenSocialの要求に従う RESTとRPCがとても密接な関係にあることは(
rest-client が便利
さてすでに書きましたが最近 API づいております。できるだけ RESTful な API を作りたいなぁと思っているわけですが、そこで問題になったのがテスト環境。 まず、ブラウザは使いものになりません。 通常の方法では GET, POST 以外のリクエストを投げられない通常の方法では html, xml, plain text な response body 以外は表示できないからです。 まぁ今回テストしたかったのは read only な API なのでリクエストメソッドとしては GET, POST だけでも問題はないのですが、response が application/json だったので 毎回毎回「ダウンロードダイアログが出る -> ダウンロード -> ファイルを開く」 作業が必要になり、さすがにこれはやっとれんと思いました。 そこでまず目をつけたのは以前インストールだけしてあっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
RESTのインピーダンスミスマッチ
IBM Developer
IBM Developer
RESTサービスのセキュリティに対処する
IBM Developer
IBM Developer
InfoQ: RESTの良い点、悪い点、ひどい点
RESTfulなJSON Webサービスのベストプラクティス
RESTとSilverlightとNew York Times
thoughtbot case studies featuring design and development projects for websites, mobile and web applications.
IBM Developer
