𝘮𝘢𝘴𝘶𝘪 @masui 「RESTアーキテクチャのおかげでWebは成功した」という表現は正しいのだろうか? 「Webは成功した。Webの特徴はRESTという風に表現できる」ということはないのだろうか? 2010-05-08 23:20:45
𝘮𝘢𝘴𝘶𝘪 @masui 「RESTアーキテクチャのおかげでWebは成功した」という表現は正しいのだろうか? 「Webは成功した。Webの特徴はRESTという風に表現できる」ということはないのだろうか? 2010-05-08 23:20:45
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という2つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON(XMLでもかまわない)をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく(ずる=本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事)
http://www.infoq.com/jp/news/2009/08/CRUDREST 上記URLを読んで自分なりに例題を考えてみる。(todo:あとで状態遷移図を追加) RestBucks cafe 完全にオンライン化されていてWebAPIで注文できるというすごいカフェを想定します。(この手の例にStarbucksを使うのはGregor Hopeさん以来の伝統らしいです) 客側から見たユースケースはこんな感じ 客はレジのサービスを呼び出して、注文を入力して支払い 自席で注文状況をチェック、出来上がっていたら取りに行く。 注文というエンティティと、[注文編集] [支払い] [受け取り] という(アプリケーション)状態によって上手く表現できそうです。 (RESTfulだけど)CRUDな設計 CURDな設計では、リソースをURLにマッピングします。それに対してCRUDするというイメージです
エンタープライズ向けのシステムはともかく、個人で作るサービスや自社のWebサービス構築においてクラウドをもっと活用すべきだ。ハードウェア資産やデータベースのメンテナンスなどに頭を悩ますこともなく、作りたいものを作れる環境が得られるようになる。 HTTPを使ってデータをストア、取得する データをストアする仕組みを考える際に、ついデータベースを頼りたくなるが本当にデータベースに入れる必要があるだろうか。並び替えや絞り込みをしないなら、もっと単純なデータストアでも十分なはず。そこで見てみたいのがCloudKitだ。 今回紹介するオープンソース・ソフトウェアはCloudKit、RESTfulなJSONデータストアシステムだ。 CloudKitはRubyで作られたシステムであり、HTTPを使ってデータベースにアクセスする。ストアする際も、取得する際も利用するのはJSON形式だ。スキーマの定義など気に
先ごろ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がとても密接な関係にあることは(
さてすでに書きましたが最近 API づいております。できるだけ RESTful な API を作りたいなぁと思っているわけですが、そこで問題になったのがテスト環境。 まず、ブラウザは使いものになりません。 通常の方法では GET, POST 以外のリクエストを投げられない通常の方法では html, xml, plain text な response body 以外は表示できないからです。 まぁ今回テストしたかったのは read only な API なのでリクエストメソッドとしては GET, POST だけでも問題はないのですが、response が application/json だったので 毎回毎回「ダウンロードダイアログが出る -> ダウンロード -> ファイルを開く」 作業が必要になり、さすがにこれはやっとれんと思いました。 そこでまず目をつけたのは以前インストールだけしてあっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く