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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
