Ruby製Webアプリでの書式チェック用正規表現 - 岩本隆史の日記帳（アーカイブ）
制御文字は不許可にすべき 前回の日記で「単なる書式チェック（文字種や長さなどのチェック）なので、アプリの要件にしたがって粛々と行えばよい」と書いた「(c)パラメータ文字列の妥当性検証」であるが、実は考えるべきことがそれなりにある。アプリの要件として、各パラメータの「許容文字種」と「許容文字数」を決める必要があるのだ。 このうち許容文字数については話が簡単である。最短および最長の許容文字数を決め、入力値がそれを外れていたらエラーにすればよいだけだ。 問題は許容文字種である。たとえば電話番号の入力を想定したパラメータ文字列であれば「数字またはハイフン」が許容文字種となるだろう。では住所欄や感想欄はどうか。あらゆる文字を受け入れてよいのだろうか。 もちろんアプリによってはあらゆる文字を受け入れなければならない場合もあるだろう。しかし「第11回■制御文字や不正な文字エンコーディングによるぜい弱性を
こんなURI設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク
RESTクライアントが知っているべきこと - 岩本隆史の日記帳（アーカイブ）
クライアントとサーバの密結合を避けられるのが、RESTスタイルに従って得られるメリットのひとつです。クライアントが、アプリケーションの挙動に関する知識をほとんど持たなくてよいわけです。 とはいっても、まったく何も知らないではクライアントたりえません。では、何を知っていればよいのでしょうか。 知っているべき4点 その答えは、Roy T. Fielding による記事「REST APIs must be hypertext-driven」で、すでに示されています。下記の4つです。 通信プロトコル（communication protocol） 初期URI（initial URI） メディアタイプ（media types） リンク関係（link relations） AtomPubを例にとると分かりやすいでしょう。 通信プロトコル＝HTTP 初期URI＝サービス文書のURI メディアタイプ＝「a
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
HTTPの仕様からRESTfulなWebアプリのMVCを見直す - 岩本隆史の日記帳（アーカイブ）
Smalltalk由来のMVCとWebアプリのMVC 最近、WebアプリにおけるMVCに関する記事をふたつ書きました。 WebアプリでもSmalltalkのMVCパターンが使えるかも サーバサイドでSmalltalkのMVCパターンを使うのは無理があるかも これらの記事で私が想定しているのは、GUIのフォームに何らかの文字列を入力してボタンを押すと、モデルの内容が変更され、その変更を感知したビューが自身を書きかえるという、Smalltalk由来のMVCです。 Webアプリのフレームワークで俗にMVCとよばれる実装は、Controllerのメインメソッドの中でModelを変更し、Viewのインスタンスを作って変更結果をassignする手法です。私はこれが嫌いで、Smalltalk由来のMVCをWebアプリで使いたくなったわけです。 このことは、ひとつめの記事にも書きました。 私は以前から、W
続・コマンド的な処理をどうやってRESTfulに実装するか - 岩本隆史の日記帳（アーカイブ）
「コマンド的な処理をどうやってRESTfulに実装するか」に書いた内容を敷衍します。 SunのクラウドサービスAPI 先日、Sun MicrosystemsがSun Cloudというクラウドサービスを提供すると発表しました。 米Sun、Amazon対抗のクラウドサービス「Sun Cloud」を発表 - SourceForge.JP Magazine この記事には、クラウド操作用APIがRESTベースで提供される予定であることも書かれています。 Sunは開発者向けにクラウドAPI「Sun Open Cloud API」を提供する。RESTベースのAPIで、CreativeCommonsライセンスの下でリリースするため、開発者はSun Cloudと相互運用性のあるクラウドを構築できるという。 そのAPI仕様のドラフトが「The APIs for the Sun Cloud: Wiki: Hom
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
