InfoQ Software Architects' Newsletter A monthly overview of things you need to know as an architect or aspiring architect. View an example
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
先日のQConで大場さんもおっしゃっていたことですが、Railsで開発をする上でものすごく重要なポイントに、Railsの敷いたレールから降りないというのがあります。別にコレはRailsが不自由だというわけでなく*1、通り一遍のものしかできないというわけでもなく、ただ基盤と相性の悪い設計すればあとで苦労するという、当然の話なわけです。 最近、私を含めいろいろな方が「レールから降りないで作るのが重要」と話しています。が。じゃあそのレールはどこにあるのかという話はあまり聞かれません。ということで、ふだん私がRailsアプリを設計するときに意識しているレールを言語化してみて、議論なりのたたき台にしたいな、と思った次第です。 とはいえDB周りは「羽生さんのERDレッスン嫁」で7割くらい済む話*2なので、まずはコントローラから。 設計指針としてのmap.resouces Rails 2.xにおいて、コ
リソース指向な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
今日はRESTfulについてのお話。 RESTとはRepresentational State Transferの略称で、ウェブサービスのインターフェースとしての分かりやすい設計の新しい手段として使われ始めている技術です。 RESTfulなウェブサービスの具体的な実装の4つの基本原則が HTTPメソッド(POSTとかGETとか)を明示的に使う ステートレスにする URIをディレクトリに似た階層構造にする XML,JSONのいずれか,または両方を転送する となっています。 では実際に現在主に使われているやり方とRESTfulなウェブサービスとの違いを考えてみます。 というか自分で理解した中で疑問も合わせて書いてみます。 1.HTTPメソッドをCRUDモデルに当てはめて,ディレクトリ構造のURIと対応させる 現状は特に意識せずにファイル名をそのままURIにしたり、mod_rewriteを使って
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
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
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 メソッドを適用していくか,と
本日より、ricollabの語源の一つである「リコーラボ」としての活動の第一弾、郵便番号検索サービスを開始します。 同時に、このブログのサーバも社内のマシンルームから外部のデータセンターに移動して、心機一転です。読者の皆さんにはサーバの場所が変わってもあまり関係ないかもしれませんが、法定点検による停電の心配などが無くなりました。 「何でリコーが郵便番号なの?」という疑問も大いにあるかとは思いますが、いろいろなサービスで使われる情報なので応用が利くというのと、Webサービスとしてまずは小規模なところからスタートし、サーバの運営やWebサービスの提供までの設計・開発ノウハウを蓄積していこうという狙いがあります。 ただし、小規模なアプリとは言ってもただ単に日本郵便のゆうびんホームページで公開されている郵便番号データを検索できるようにするだけではつまらないので、山本がガチで設計したRESTfulな
日々のプログラミングの雑感です。 やはり仕事のプログラミングですと、他の方が書かれたプログラムを修正して....というのが、大きなウェイトを占めるのは当然です。このとき、いつも私が気になること、というとか「私がいつも気をつけて実践している、複雑さを低減する有効な手段なんだけども、あまり他の人が理解していない」と見受けられることについて書きましょうか。 その基準、というようなものは、単純にこのコトバで表せます。ゲッタは、外部から見える副作用を持つべきではない ということです。この原則を私が理解し受け入れたのは、やはり Meyer の「オブジェクト指向入門」での主張がきっかけです。Meyer が作った言語 Eiffel は Pascal(Ada)ベースですから、値を返す function(関数)← Java だとゲッタはこれ と、値を返さない procedure(手続) ← Java での典型
Update 1: Wow, apparently using Atom as an example was a bad idea given the number of people with their knickers in a twist. Update 2: Fixed the URI Template to accomodate Sam's nose. Update 3: Good feedback from Tim Bray, Mark Nottingham, and Rob Sayre. There are times when you have a large representation of a resource and only want to edit a small part of that resource. Wikipedia is a good examp
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
http://comments.gmane.org/gmane.comp.web.services.rest/6149 最初のメッセージではこんなことを書いている まず、ActiveMQ の(その当時の) REST API の抜粋: POST で in, GET or DELETE で out GET が read-only なのは、REST じゃなくて HTTP キューを表す URL への DELETE は、キュー全体の削除を意味する これはリストに投げたのは、面白いケースで、即座にはより良い方法を思いつかなかったからだ このエントリでは、キューへ突っ込むのを in, 取り出すのを out と書くことにする。POST/GET は HTTP メソッドのこと。 次のエントリでは、POST-GET-DELETE という提案がある。http://permalink.gmane.org/gmane
RESTful APIリファレンス こみゅすけが提供するREST APIを利用することで、こみゅすけが管理する情報をRESTfulな手順で参照および更新することが可能です。 つまり、従来から公開されているこみゅすけのUIを利用するのではなく、REST APIを利用した独自のアプリケーションを、利用者自身が作成することが可能となります。 利用条件 こみゅすけは、利用してくれる皆さんが自由に情報交換を行えるように、という思想から、ユーザ認証などの仕組みを採用していませんし、今後も採用しないでいきたいと考えております。RESTful APIについても同様の考えから、認証機能は搭載せず、誰もがAPIを使って、こみゅすけの情報を使ってアプリケーションを構築あるいは二次利用できるようにしています。 皆さんの常識あるアクセスが基本となりますので、不正な行為や悪質な行為などは絶対に行わないでください。 ま
Implementing REST Web Services: Best Practices and Guidelines August 11, 2004 Hao He Despite the lack of vendor support, Representational State Transfer (REST) web services have won the hearts of many working developers. For example, Amazon's web services have both SOAP and REST interfaces, and 85% of the usage is on the REST interface. Compared with other styles of web services, REST is easy to i
前回の続きです。 stompserver に RESTful な口があるようなので今回はそちらを見てみます。 まずは、bin/stompserver を弄ります。 $HTTP_ENABLE をtrue にするだけです。これで、http.rb が読みこまれ、HTTPハンドラが開始されます。 - $HTTP_ENABLE = false + $HTTP_ENABLE = true If $HTTP_ENABLE require 'mongrel' require 'stomp_server/protocols/http' end ... if $HTTP_ENABLE puts "Http protocol handler starting on #{config.opts[:host]} port 8080" EventMachine.start_server(config.opts[:ho
RESTful な HTTP の使いかたという文脈で、特に構造を持たないような集合をリソースとして、CRUD を行うという話はよくある。(cf. http://yohei-y.blogspot.com/2005/04/rest-5-get-post-put-delete.html) では、キュー(FIFO なデータ構造)を扱うにはどのように構成したらよいのか? と考えはじめて分からなくなった。 head には突っ込むことだけが出来る tail からは取り出しだけが出来る その他の要素には(管理とかは置いといて)アクセスできない PUT/DELETE の羃等を知らなかったときには、キュー(queue.hoge という名前だとする)をリソースと見立てて、 PUT /queue.hoge で head に突っ込む DELETE /queue.hoge で tail から取り出す でいいのかなぁ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く