Is CRUD Bad for REST?InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architects. View an example Memorial Day Sale: Save up to 60% on InfoQ Dev Summit Boston (June 24-25)
Seasar Conference 2006 Spring (5) - 世界線航跡蔵
前の記事 に続いてSeasar Conferenceをレポートする。 セッション4 DB-sideのほうは「EJB3時代のERDレッスン - Activity Based Datamodel」 Seasar-sideのほうは「片手でスイスイWebアプリ2.0 - Tuigwaa劇場へようこそ」 ミニセッションのほうは「S2Flex2」 Tuigwaaのセッションは聴衆を感動と興奮の渦に巻き込んだらしいけれど、それは想像に難くない。 千葉滋PM採択案件最終成果報告会 で一応話は聞いて、私も非常に感動した。 Tuigwaaは一度聞いたからいいやと思って、私は「ERDレッスン」を聞いてきた。 はぶさん ERDセッションの発表者は、はぶあきひろさん。御本人を見るのは初めてで、少しイメージが違った。 はぶにっき は愛読しているけれども、偶に、SIerさんが書いていると想像するとちょっと鼻につくように
The Amazing Blog : Your Web Service Might Not Be RESTful If…
Rando’s Random RamblingsThe other day, I gave a brief talk about our HTTP Library, Resourceful. After a few minutes of going over the features, it became apparent to me that very few people have taken the time to appreciate the finer points of HTTP. Everyone who calls themself a web application developer needs to take a few hours to read RFC2616: Hypertext Transfer Protocol — HTTP/1.1. Its not ve
Tell, Don't Ask | The Pragmatic Bookshelf
This website uses cookies for account and order processing. By using this site you understand and agree to our use of cookies, our Terms Of Use, and Privacy Policy Alec Sharp, in the recent book Smalltalk by Example [SHARP], points up a very valuable lesson in few words: Procedural code gets information then makes decisions. Object-oriented code tells objects to do things. — Alec Sharp That is, yo
ぼくが見ているレール(map.resouces編) - moroの日記
先日のQConで大場さんもおっしゃっていたことですが、Railsで開発をする上でものすごく重要なポイントに、Railsの敷いたレールから降りないというのがあります。別にコレはRailsが不自由だというわけでなく*1、通り一遍のものしかできないというわけでもなく、ただ基盤と相性の悪い設計すればあとで苦労するという、当然の話なわけです。 最近、私を含めいろいろな方が「レールから降りないで作るのが重要」と話しています。が。じゃあそのレールはどこにあるのかという話はあまり聞かれません。ということで、ふだん私がRailsアプリを設計するときに意識しているレールを言語化してみて、議論なりのたたき台にしたいな、と思った次第です。 とはいえDB周りは「羽生さんのERDレッスン嫁」で7割くらい済む話*2なので、まずはコントローラから。 設計指針としてのmap.resouces Rails 2.xにおいて、コ
プロセス志向のデータベース設計 (mark-wada blog)
このあいだ、「SOA時代のデータ管理」というエントリーを書いたが、そこではデータベース設計をどうやるかには言及していない。それで、最近そのことについてずっと考えているが、なかなか答えが見つからない。 データベース設計というと、DOAが浮かんできます。データ総研の椿さんはいつも、DOAの条件として、「データ先行・リソース先行・概念先行」ということをおっしゃっています。データをプロセス／処理に先行して考え、イベントデー タ（受注・出荷・請求など）より先にリソースデータ（社員・顧客・商品など）を固め、物理データベースより概念データベースを先行するという意味です。 では、POA（という言葉があるとすれば）だとどうなるのでしょうか。「プロセス先行・マクロプロセス先行・概念先行」といったところでしょうか。しかしデータベースはどうするのだの答えにはなっていません。 DOAだと一般的に言われるのは、画面と
Site-it!: DESIGN IT! w/LOVE
不確実な時代をクネクネ蛇行しながら道を切りひらく非線形型ブログ。人間の思考の形の変遷を探求することをライフワークに。 これはいい！って思いました。これ考えた長谷川さんすごい。金曜日の第3回情報デザイン・フォーラムで、コンセントの長谷川さんが紹介していたSite-it!。 これはいい！って思いました。これ考えた長谷川さんすごい。 どういうものかというと、プレゼンシートに書いてあったことをそのまま引用しておくと以下の通り。 ウェブサイトの典型的なページをテンプレート化した付箋ノートです。このSite-it!を用いて自由にブレインストーミングを行うことができます。白紙の付箋よりイメージがつかみやすく、PC＋プロジェクターを使うより自由に議論ができ、そしてなにより紙なので安い！Site-it!によって、クライアントも巻き込んで、より柔軟にサイトストラクチャを議論してください。 これ使って、サイトの
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 この
リソース指向なgeo+webのサブクラス - Relevant, Timely, and Accurate
リソース指向なgeo+webのサブクラスの定義を試みます。 convivial-weblog さんから。 RESTfulは、リソース指向的な考えに基づいたアーキテクチャなので、何かしらの処理を関数的に実行させたい場合などは、RPC（Remote Procedure Call）的に呼び出せる「なんちゃってREST」の方が適しているケースも多いように思います。 http://convivial-web.com/blog/2009/03/restrestful.html 関数的に呼び出す形のものはやはり RPC 的にしておくのがよさそうだと思っています。OGC の規格でよくある、引き出し対象を任意の矩形で指定するようなパターンは、典型的に RPC 的なパターンであると考えており、あのパターンを RESTful にすることは至難だと思います。 geo+web の特徴の分析から、そのような RPC
システムアーキテクチャ構築の原理 - 廻る技術の覗き穴
システムアーキテクチャ構築の原理 ITアーキテクトが持つべき3つの思考 (IT Architects’Archive ソフトウェア開発の実践) 作者: ニック・ロザンスキ,イオイン・ウッズ,榊原彰,牧野祐子出版社/メーカー: 翔泳社発売日: 2008/12/03メディア: 大型本購入: 15人 クリック: 355回この商品を含むブログ (16件) を見る アーキテクチャ設計の際には、ぜひ手元に置いておきたい一冊。 設計に関する書籍はスタイルやパターンについて書かれたものが多いが、本書はステークホルダ、スコープ、パターンに始まり、データ構造、運用、セキュリティ、パフォーマンスなど取り扱う範囲が非常に広い。 しかし網羅性は高いものの、各項目はそれほど詳細に記述されているわけではない。詳しく学びたい場合は、各章で参考文献が紹介されているので、それらを参考にするのがよいだろう。 また、実際の設計の
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を使って
Whatfettle - Paul Downey (psd)
Roy Fielding is on something of a crusade, pushing back on many publishers of HTTP interfaces who claim to be RESTful. I particularly like the latest: REST APIs Must be Hypertext Driven. Unfortunately the Word of Roy may be a little too divine for comprehension by many sinners, so at the risk of invoking the wrath of the posse, I'll try and simplify. If you insist on using the word "REST" in assoc
REST APIs must be hypertext-driven » Untangled
I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating. What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application stat
rws-reading に行ってきた - 烏賊様
id:ZIGOROu に連れてくると言われたままペンディングしていたので，今回行ってきました． http://kunit.jp/restful/wiki/index.php?%C2%E86%B2%F3%CA%D9%B6%AF%B2%F1 会場は株式会社ディノさんのセミナールームで，会場提供のみならず，なんとビールが振る舞われました．ディノ++ 以下，感想というよりは，たけまるさんの問いに答えておく． AtomPub が標準化されて楽になりましたか？ サービス実装という立場で考えると「楽になった部分と変わらない部分がある」と思う． AtomPub は，あさくらさんも言われていたように Atom Publishing Protocol という名前のプロトコル仕様の域にあるものだと思う．その観点で考えると（あらかじめリソースが定義されてるとして）そこにどう HTTP メソッドを適用していくか，と
「ペルソナ／シナリオ法による商品・サービス開発」セミナー 株式会社イード :: マーケティングセミナー案内
6月24日開催の【ペルソナ作って、それからどうするの？」出版記念セミナー】には多くのお客様にご盛況賜りまして、誠にありがとうございました。 「ペルソナ作って、それからどうするの？」出版記念セミナー第２弾の今回は、弊社チーフコンサルタントの棚橋弘季による講演の他、千葉工業大学工学部デザイン学科教授の山崎和彦氏、大和ハウス工業株式会社の山口氏をゲストスピーカーにお招きし、ペルソナ／シナリオ法について、その概念、構築の仕方、事例をご紹介いたします。 ユーザー中心設計、およびユーザー中心設計において「誰のためのデザインなのか？」という視点から具体的なデザインコンセプトを明示するための手法であるペルソナ／シナリオ法についてご理解をいただく機会になるものと思います。ご多忙中とは存じますが、皆様のご参加を心よりお待ち申し上げております。 7月30日開催の「ペルソナ／シナリオ法による商品・サービス開発」セ
インターフェイス指向設計
本書はインターフェイスを用いたソフトウェア設計の仕組みを解説する本です。ソリューションをインターフェイスのレベルにまで分解し、相互作用するインターフェイスを適切に実装して、しっかりとした構造を持つプログラムを作成する手法を学びます。インターフェイスの凝集度とは、継承の利点、リモートインターフェイスとの通信など、基礎となる知識から、開発プロセスについて、Web自動集約ツール、サービスレジストリなど、発展的な内容まで、「インターフェイスから考える設計」についてを包括的に学びます。 最初に完璧をめざすのではなく「まず動くものをつくる」というアジャイル開発手法でインターフェイス設計を学ぶ本書は、より信頼度の高いソフトウェアを開発したい技術者必携の一冊です。 監訳者まえがき はじめに I部 インターフェイスのすべて 1章 インターフェイスとは何か 1.1 ピザを注文するインターフェイス 1.1.1
ricollab Web Tech Blog » Blog Archive » ricollab実験サービス第一弾を開始します!
本日より、ricollabの語源の一つである「リコーラボ」としての活動の第一弾、郵便番号検索サービスを開始します。 同時に、このブログのサーバも社内のマシンルームから外部のデータセンターに移動して、心機一転です。読者の皆さんにはサーバの場所が変わってもあまり関係ないかもしれませんが、法定点検による停電の心配などが無くなりました。 「何でリコーが郵便番号なの?」という疑問も大いにあるかとは思いますが、いろいろなサービスで使われる情報なので応用が利くというのと、Webサービスとしてまずは小規模なところからスタートし、サーバの運営やWebサービスの提供までの設計・開発ノウハウを蓄積していこうという狙いがあります。 ただし、小規模なアプリとは言ってもただ単に日本郵便のゆうびんホームページで公開されている郵便番号データを検索できるようにするだけではつまらないので、山本がガチで設計したRESTfulな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Web Things, by Mark Baker » Interface included
The JUI 2008 Tokyo の資料を公開します - inucaraの日記
On software architecture » Untangled