WCFとSOAP・REST - qnzm.log(クニジマログ)
WCF勉強中につき、メモ書きです。 『インサイドWindows Communication Foundation』を読みながら、関連を調べてという形で進めてます。 『インサイドWindows Communication Foundation』によれば、WCFは当初SOAP/WS-*を前提としている部分が大きかった様子。JSONなどの台頭自体はWCF開発チームにとって予想外だったのでは？という記載があった。JSONというか、RESTアーキテクチャスタイル。 WCFはSOAP, REST, POXをサポートしています。ただし、現在のWCF APIのほとんどは、SOAPメッセージ構造にのみ対応しています。 将来的には、JSONなどのほかのメッセージング構造にも対応するように拡張される予定です。 『インサイドWindows Communication Foundation/p.28』 ※POXは「
「Webを支える技術」。Webアーキテクチャを知り、Webサービスを設計するための一冊
日本にREST（Representational State Transfer）と呼ばれるWebのアーキテクチャスタイルを広めた山本陽平氏から、「本を出版するので送りたい」という連絡をいただいたのが約1カ月前。送られてきたのがこの本「Webを支える技術」でした。 山本氏のブログを拝見すると、約1年ほどはこの本の執筆に取り組んでいたご様子。中味を読んでみればそれも納得です。 本書はWebを支える3つの技術、HTTP、URI、HTMLを中心にWebのアーキテクチャを詳しく解説することから始まり、Webのアーキテクチャに沿ってWebアプリケーションや（広義の）Webサービスをどう適切に設計していくべきなのか、という、Webアプリケーションを開発するときに必ず考慮しなければならない課題を解決する道筋を教えてくれます。 Webアプリケーションをどう設計するべきか、大事なことなのに、これまでこれほど十
yohei-y:weblog: 『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました
このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっと本を書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名の本です。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。 Webを支える技術 ── HTTP、URI、HTML、そしてREST山本 陽平技術評論社 2010-04-08 この本は、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のある本が書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
このドメインは お名前.com から取得されました。 お名前.com は GMOインターネットグループ(株) が運営する国内シェアNo.1のドメイン登録サービスです。 ※表示価格は、全て税込です。 ※サービス品質維持のため、一時的に対象となる料金へ一定割合の「サービス維持調整費」を加算させていただきます。 ※1 「国内シェア」は、ICANN(インターネットのドメイン名などの資源を管理する非営利団体)の公表数値をもとに集計。gTLDが集計の対象。 日本のドメイン登録業者(レジストラ)（「ICANNがレジストラとして認定した企業」一覧（InterNIC提供）内に「Japan」の記載があるもの）を対象。 レジストラ「GMO Internet Group, Inc. d/b/a Onamae.com」のシェア値を集計。 2023年10月時点の調査。
関西オープンソース2009/関西Ruby会議02 - winplusの日記
以下のセッションに参加した。 ■大場寧子さんの「続・現場で役立つRuby on Railsパターン」 Ruby on Rails での大規模開発(10人程度)での経験から。アプリケーションが大きい＝複雑だと、メンテナンスが大変・変更しづらいという状況になる。なので、つねにコードを「良い状態」(効率がよく、一貫性があり、可読性が高い)に保つようにすべき。このために「実装パターン」を共有するようにした。「続」ということで、そのときに触れられなかった２つの実装パターンを紹介。 1.検証は実は奥が深い ・乱用しない：Railsのバリデーションはよく出来ているので、いろんなチェックをすべてこれで行ってしまいがち。でも、検証はエラー処理ではない。「ユーザが許可された操作によって」発生した不正な状態のみを対象とすべき。そのためにキレイな表示画面とかも用意されているのだから。エラー処理はコールバックとか例
2008-03-02
2/29（金）、3/1（土）の2日間開催されたOSC2008 Tokyo/Springが無事終了しました。MapleおよびUsagi関係者のみなさんお疲れ様でした。各自忙しい中、現時点であれ以上の準備はできなかっただろうというものになったと思います。今回のものを一度きちんと「ふりかえり」をして、次回以降のイベントはもっといいものにしていきましょう。 印象に残った点をいくつか思いつくままに。 続きを読む OSC2008 Tokyo/Springの金曜日の夕方に「REST勉強会」とだけ告知して行いました。 内容をダンプしてみると・・・ 続きを読む OSC2008 Tokyo/Springの土曜日の昼一で「Maple×Usagi」のコラボで発表を行いました。 内容をダンプしてみると・・・ 続きを読む OSC金曜日のセッションが終わったあとに和田さんと話していたんですが、PHPだからこそRESTな
今回のテーマ - 紫水晶の和
「性懲りもなくRedmineを改造してみる」>>> 改めRESTについて 「愛されたい！」と思ったときにJavaを使ってRubyクラスを書く方法 帰ったらすぐに使いたくなるgit入門 改めRESTについて RedMineの紹介が終わって、YuguiさんからWebサービスの定義の説明。 認証が絡んでRESTのあるべき姿を追求していって、最終的にはRedMineに戻ってこれなかった。 ポイント １．GetはRESTを意識したほうが良い。 ２．認証はRESTで加味しない方が良い。 ３．updateは206で応答、200のno contentはURL新規作成のため使い分けた方が良い。 後の中華屋懇親会で、舞波さんから「Rails2.0系からActionWebServiceなぜなくなった」とか、t-wadaさんからセッションのフォローが入る。「RESTはこうあるべき」という討論は熱が入って気持ち良い
Rails勉強会#32レポート - Hello, world! - s21g
Rails勉強会＠東京第32回 に参加してきました。 お盆の最中だったせいか、いつもの半分ぐらいの参加者でした。 そのせいか、いつもとちょっと違ったRails勉強会となりました。 シングルトラック 3セッション 自己紹介が最後 これがなかなか良かったです。 ただ、人数が多いとできない形式でしょうね。 実際に行われたセッションは以下の通り。 YuguiさんによるRedmineの話(実質は高橋会長によるRESTトーク) 大場さんによるJRubyで拡張を作る話 西さんによるgitの話（入門から仕事で使えるレベルまで） いずれもハイクオリティなセッションで面白かったです。 僕はgitの話でちょっと話をしました。 リポジトリ間で相互のpush/pullするのが出来たので満足。 それから、git-instawebやgit-guiという、 Git用のGUIツールがある事を教わりました。
社内のREST勉強会に出て考えたこと - uehaj's blog
RESTfulアーキテクチャは「考え方」。これに始まりこれに戻る。 開発したシステムがRESTのいくつかの特徴に当てはまっても、考え方が違ってたらそれはRESTfulではない。たとえば、最初からページ指向に作ってきたアプリに、見たところそれらしいURLを最後に付与してみたとしても、RESTfulな精神に従ってないなら、RESTfulと呼べない(かもしれない)。 逆に、システムの設計思想が基本的にRESTfulな考え方(RESTfulな考え方の各段階）にしたがっていたなら、それはシステムのいくつかの特徴がRESTfulと反するものであっても、依然としてRESTfulでありうる。たとえば、（何らかの現実的制約により）直感的なＵＲＬにはなっていなかったとしても、RESTful な精神を生かしていると言い得る。 ではその考え方とは何か。思うに、以下の「順序」で考えることも重要なのではないかと。 な
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
{{title}}
ぷっちん日記(2008-01-21)