HTTPの仕様書に「副作用」の定義がないのは不親切じゃね？ - 岩本隆史の日記帳（アーカイブ）
『Webを支える技術』の101ページに、こう書かれています。 リソースの状態に変化を与えることを副作用（Side Effect）と言います 僕の読み落としでなければ、この定義の出典は同書には明記されていません。ただ、HTTPメソッドの冪等性や安全性を解説する文脈で紹介されているので、HTTP/1.1の仕様書であるRFC 2616が出典なのだろうと思います。 RFC 2616の本文には、「副作用」（side-effects あるいは side effects）という言葉が9回出てきます。最初に出てくるのは「9.1.1 Safe Methods」においてです。橋本英彦さんによる日本語訳を引用します（強調は岩本、以下同じ）。 本質的に、サーバが GET リクエストを実行した結果として副作用を起こさないという事を保証するのは不可能であり、事実、いくつかの動的なリソースはそれが特徴であると考えている
続・こんなURI 設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いた「こんなURI 設計、どう？」の続きです。 例：商品ブックマークサービス URI設計の例として、商品ブックマークサービスを対象に考えてみます。提供するおもなリソースは、以下の5つです。 リソース名 パンくずリストのイメージ トップレベルリソース トップ ユーザ登録画面リソース トップ＞ユーザ登録 ユーザ別ブックマークリソース トップ＞iwamotのブックマーク ブックマークリソース トップ＞iwamotのブックマーク＞Webを支える技術 商品リソース トップ＞Webを支える技術 うち商品リソースについては、はてなブックマークのエントリページ（例：http://b.hatena.ne.jp/entry/twitter.com/）みたいなものとお考えください。商品ブックマークサービスでは、entry以下のURI断片の代わりに、Amazonの商品コード（ASIN）を用いることにします。
何をクラス分割の指針とすべきか - 岩本隆史の日記帳（アーカイブ）
最近なんとなく： クラスの保持するインスタンス変数をなるべく少なくする インスタンス変数を使わないメソッドをクラスに含めない ようにすれば適切にクラス分割できるんじゃないかと考えていました。 今日「凝集度と結合度：このコードのどこが悪いのか？ - ITmedia エンタープライズ」という記事を読み、基本的にこのような考え方で間違いなさそうだと自信が持てました。 LCOM（Lack of Cohesion in Methods） その記事では、いわゆる凝集度（の欠乏度）の測定手法として、LCOM（Lack of Cohesion in Methods）という計算式が紹介されています。インスタンス変数の数、メソッドの数、そして各インスタンス変数にアクセスするメソッドの数を用いて、計算結果が0に近いほど凝集度が高いクラスとみなす手法です。 記事に掲載されている凝集度の低いクラスの例はこういうもの
私が RESTful API の後方互換性を気にするケース - 岩本隆史の日記帳（アーカイブ）
前回の記事「RESTクライアントが知っているべきこと」に、id:nsiena さんからトラックバックをいただきました。 RESTful API の後方互換性 - Siena.の日記 斜め上の応答になってしまうかもしれませんが、思ったことを書いてみます。 API変更の性格分類とサーバがとりうる対策 まず、APIがどのように変更されるか分類し、サーバが取りうる対策をまとめてみましょう。 API変更の性格 サーバがとりうる対策（概要のみ） リソースのURIが変わる ステータスコードで「301 Moved Permanently」を返し、Locationヘッダで新規URIを返す。 リソースのメディアタイプが変わる Content-Typeヘッダで適切なメディアタイプを返す。リクエストのAcceptヘッダによっては、ステータスコードで「406 Not Acceptable」を返さなければならないかも
WebアプリケーションフレームワークにおけるHTTPステータスコードの扱い方 - 岩本隆史の日記帳（アーカイブ）
最近、HTTPやらWADLやらMVCやらについて考えていたのは、Webアプリケーションフレームワーク*1を自作する*2うえで必要な作業だったからでした。方向性は見えてきた（と思いたい）ので、今回は「フレームワークにおいてHTTPステータスコードをどう扱うべきか」について考えてみます。 さきに断っておきますが、「HTTPステータスコードをどう扱うべきか」はフレームワークの数だけ答えがあると私は思っています。これから書くのは個人的な好みによる設計判断であることをご了承ください。 Alan Dean氏の図はしっくりこない どのような状況でどのようなHTTPステータスコードを返すべきかについてAlan Dean氏がまとめたダイアグラムがあります。一見、この図をそのままフレームワークに適用すれば考えるまでもないように思えるのですが、下記の2点から、どうも私にはしっくりこないのです。 認証状況の確認フ
Webアプリにおける適切なレスポンスボディとは - 岩本隆史の日記帳（アーカイブ）
「HTTPの仕様からWebアプリのMVCを見直す」という記事を書きながら、Webアプリにおける適切なレスポンスボディとはどのようなものなのか、あらためて考える必要があると感じました。今回の記事はその実践です。 考えるべきケース まず下記のようなケースは、答えが自明であり、考えるまでもないものです。 要求されたリソースの表現を返せばよい場合（例：GETで「200 OK」） レスポンスボディを返してはならない場合（例：「204 No Content」「304 Not Modified」） そのように処理すればよいだけだからです。 考えるべきは、下記のようなケースです。 正常に処理されたことを伝えたい場合（例：PUTで「200 OK」） 他のリソースを参照させたい場合（例：「201 Created」「303 See Other」） クライアントに入力値の修正をうながしたい場合（例：「400 Ba
ETagをどう生成するか - 岩本隆史の日記帳（アーカイブ）
ETagとは何か ETagはHTTPレスポンスヘッダのひとつで、RFC 2616の14.19（日本語訳）で規定されています。If-None-Matchリクエストヘッダを使った条件付きGETでの転送量軽減や、If-Matchを使った条件付きPUTでの競合検出などに使われる値です。 強いETag、弱いETag ETag（エンティティタグ）には強弱があります。簡単にいえば、HTML内のアクセスカウンタが1上がっただけで変わるのが強いETag、変わらないのが弱いETagです。弱いETagは、リソースの意味が変わらなければ変わりません。 同13.3.4では「HTTP/1.1 オリジンサーバにとってより望まれる動作とは強いエンティティタグと Last-Modified 値の両方を送る事である」とされています。なるべく強いETagを使いましょう、ということです。 Rails2.0の生成手法 「http:
IBM社のCouchDBセミナーに参加した - 岩本隆史の日記帳（アーカイブ）
昨晩、IBM社主催のセミナー「CouchDB で始める Web 時代のデータベースとの付き合い方 - Time to relax!!」に参加しました。長野への日帰り出張後という強行日程でしたが、MapReduceの概要などがつかめたので、がんばって参加したかいがあったと思います。 セミナーは、CouchDBの概要、RESTful APIの使い方、MapReduceのデモという3部構成でした。資料が後日公開されるそうなので、詳細はそちらでご確認ください。 個人的に興味深かった点を、備忘録を兼ねてメモしておきます。 リビジョン管理の仕組みが面白い データを登録するとリビジョン番号が振られ、更新時や削除時にはそのリビジョン番号のマッチング処理を行う、という仕組みが面白いと思いました（参考）。 WikiやISO文書管理システムなどとの相性も良いでしょうし、排他制御の必要なシステムでも威力を発揮する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
