L'eclat des jours(2011-06-03)
_ RESTとCSRF RESTの特性のサーバサイドステートレスという点にこだわりすぎると、CSRF自由自在となってしまう。というよりもどこからでも破壊的なメソッドを受け付けるようにしているのだから、CSRFではなく、単にそういうAPIだということだ。 それらのAPIの最初の時点で認証があれば、少なくともその操作を許可されているのだから（あるいは認証された領域外は許可されていないのだから）あまり考える必要はないと思う。 そうではなく、認証されていないクライアントが所定の遷移に従わなければ破壊的な操作を行えないようにするにはどうすれば良いのだろうか。 すると、HATEOASを使うということを思いつく。いきなり、POST/PUT/PATCH/DELETEできるというAPIでは無く、最初は必ずクライアントからのGETで始まるとする。そして各操作をeditリレーションのリンクで示す。たとえばGET
REST in Practice
Read it now on the O’Reilly learning platform with a 10-day free trial. O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers. Why don't typical enterprise projects go as smoothly as projects you develop for the Web? Does the REST architectural style really present a viable alternative for building distributed
エンタープライズアプリケーションのモデリングパターン | システム設計日記
ドメインモデリングの基本パターンをまとめはじめてみた。 まずは、その概要のスナップショット。 関心事オブジェクト エンタープライズアプリケーションは、「事業の関心事」を扱うための道具。 だから、モデリングパターンの基本は、事業の関心事を表現した「関心事オブジェクト」。 関心事オブジェクトは、 ◎ 識別キー （名前、番号など、関心事を特定するための情報） ◎ 固定属性 （商品の説明、連絡先など、通常は、あまり変化しない属性） ◎ 変動属性 （変化することが正常で、変化しないことが異常な属性） ◎ 集約キー （グルーピングや集計のキー） で構成する。 そのアプリケーションの主要な関心事を、「関心事オブジェクト」としてモデリングする。 状態の変化 エンタープライズアプリケーションは、関心事オブジェクトの「状態の変化」を扱うための仕組み。 ◎ 関心事オブジェクトの状態が、変化するのは、どういう時か
L'eclat des jours(2010-04-15)
_ SOAPというかWS-* HTTPバインディングが標準化されたCORBA うん、これは良いまとめだと思う。 ところで、イントラだとちょっとクールなURIというわけにはいかんな、というか、RESTfulとは言えないことになるなぁという例を考えた。というよりも逆で、RESTfulなURIをそろそろ利用してやろうかと考えたのだが、ちょっと難しいなという結論となったというか。 Webサービスでやるという前提の以下のような処理を考える。 ・認証する ・会員（当然、個人情報に対する一意識別子だ）の情報をくれ ・おらよ ここでURIに、/members/id としようかと考えたのだが、いや待て、このidは個人情報の一意識別子だ。POSTするデータそのものはイントラSSLで暗号化されるとしても、URIはむき出しだよな。これはやはりよろしくない。URIはやはりそこら中でむき出しにならざるを得ないからだ。
mca blog [A RESTful Hypermedia API in Three Easy Steps]
that's all there is to it for the data structure. here's a sample implementation of the data format. i left out the query elements an all the href attributes for now. <?xml version="1.0" encoding="utf-8"?> <list> <item> <data name="title">First Task</data> <data name="description">Produce first draft of Task media-type</data> <data name="date-due">2010-03-21</data> <data name="completed">false</da
内海 英一郎のブログ: REST の複雑性？
Web 上に展開されたサービスのいくつかは、ユーザーとのインタラクションを行う HTML ドキュメント ページ以外に、開発者向けに API を提供しています。これらは、直感的な URI と HTTP ベースのシンプルな方法でアクセスすることができ、RESTful Web サービス API と呼ばれています。僕も REST ファンの一人で、RESTafarians とまではいきませんが、WWW の生態系を支えるシンプルなスタイルをとても気に入っています。 REST (Representational State Transfer) アーキテクチャー スタイルについての概要は、Roy Fielding 氏による論文 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm または、山本陽平さんのブログ http
[REST] リクエストとレスポンスのマッピング
HTTPリクエストに対して、一般的にどんなレスポンス（ステータスコード・ヘッダー・エンティティボディ）を返すのが望ましいか（または最低限なにを用意するべきか）、をまとめてみた。指針は色々なところにあるのだけれど、ぱっと見てわかる表がほしいなと思ったので。 # ベストプラクティス的なのがどこかにありそうな気がするよ・・・＞＜。 （注）これは初心者の個人的な覚書です。またあくまで指針なので、個々のアプリの性質によって、変動は必ず生じると思っています。なにかの参考（叩き台）になれば幸いです。 メソッド 状況 ステータスコード HTTPヘッダー エンティティボディ 共通 リソースが見つからない、または教えたくない 404 Not Found なし 認証情報がない、または不適切な認証情報 401 Unauthorized WWW-Authenticate エラーの説明 許可されないアクセス（認証情報
注文をキャンセルする５つの方法 - winplusの日記
『RESTful Java with JAX-RS』「Capter2:Designing RESTful Services」のメモに、はてなブックマークで、id:IwamotoTakashiさんから興味深いコメントをいただきました。 キャンセルはPOST（のオーバーロード）がしっくりくるなあ。もしくは /orders/{id}/canceled へのPUTかな。 短いコメントなので、ちょっと勝手に推測・補足させてもらいます。前者は親リソースへ数量がマイナスの注文をPOSTするという、いわゆる赤黒伝票の処理になるのでしょう。後者はキャンセル日とかキャンセル理由といった属性をもつリソースを作成するのでしょう。ということで、注文をキャンセルする４つの方法。 メソッド URI 表現 DELETE /orders/{id}?cancle=ture （なし） PUT /orders/{id} canc
RESTfulサービスを設計する - winplusの日記
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter2:Designing RESTful Services」のメモ。目次はこちら この章では、簡単な注文入力サービスのRESTfulなインターフェイスを定義する。 オブジェクト・モデルからはじめて、まずURIを決め（アドレス可能性を満たす）、次にデータフォーマットを決め（表現指向）、最後にそれぞれのURIでどのHTTPメソッドを許可するかを決める（統一インターフェイス）。 ■オブジェクト・モデル 注文は特定の顧客に関連づけられ、いくつかの項目で構成される。項目は購入された商品の型と数量を表す。 モデルは、Order, Customer, LineItem, Product。どのモデルも
RESTへどうぞ - winplusの日記
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter1:Introduction to REST」のメモ。目次はこちら WWWは生活に欠かすことのできない一部分になっている。 でも、Webがうまくいっているのはなぜ？これほど巨大に成長できたのは？これだけ急速に拡がったのは？ Roy Fielding がこれらの疑問に答える形で、アーキテクチャの原則を特定した。これが REpresentational State Transfar(REST)。RESTの原則は以下のとおり。 到達可能なリソース RESTでは、情報（データ）のキーはリソースであり、すべてのリソースはURIで到達可能でなければならない。 統一され制約されたインターフェイス
TokyoRubyKaigi03 - ぷっちん日記(2010-03-01)
■ TokyoRubyKaigi03 昨日はTokyoRubyKaigi03に参加してきました。すごい勉強になる内容でとても面白かった。スタッフ・講師の皆様、ありがとうございました！ 私のワークショップ「routes職人への道」の資料を以下にアップしましたので、見たい人はどうぞ。参加者が少なくて残念でしたが、参加してくださった方には満足してもらえたようなので良かったと思います。この資料は、"東大のシケタイ時代" のことを思い出してキリキリ作ったのでそれなりにドリルのように使えるんじゃないかと思っています。 Railsは少し触ってるけどroutes.rbはまだよくわからない、RESTfulもよくわからない、という人におすすめです。 なお、Rails3にも触れているけど、今後の仕様のなりゆき次第で、最終形ではないとおもうので注意してください。書き方もさることながら、背景となっている世界観や、考
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ウェブアプリケーションの認証について:, そんなわけで、Cookieによるセッションを使った認証ということになるわけだが、これをこれまでは「RESTに従っていない」と思って必要悪程度に考��
mca blog [join me at #RESTFest 2010]
mca blog [GET and POST are RESTful enough]
RESTful Web Services: Principles, Patterns, Emerging Technologies (WWW2010 Tutorial)
mca blog [RESTful Profiling : XHTML-based Web APIs]
RESTのインピーダンスミスマッチ
InfoQ Explores: REST
Subbu’s Blog
Amazon.co.jp: Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ): 山本陽平: 本
