タグ

restに関するyukio2005のブックマーク (12)

  • インフォテリアがSOA新戦略,「ASTERIA」の新版をリリース

    インフォテリアは10月11日,SOAの新戦略を発表した。2006年11月から2007年1月にかけて,EIAツールの新版「ASTERIA」の新シリーズを順次リリースする。 今回,システム連携の新しいコンセプトとして「ESP:Enterprise Service Pipeline(エンタープライズ・サービス・パイプライン)」を提唱した。ESPとは,SOAを構成するESB(エンタープライズ・サービス・バス,企業内システムを連携)を進化させたもので,社内だけでなく社外のシステムやWeb上のサービスを高機能なインタフェースによって連携する。すなわちWebサービスの標準プロトコルであるSOAPだけでなく,Webアプリケーション間でデータを転送するREST(Representational State Transfer)やWeb APIによる連携もサポートする。 新版の「ASTERIA WARP」は,E

    インフォテリアがSOA新戦略,「ASTERIA」の新版をリリース
  • TechCrunch Japanese アーカイブ » SocialTextが目指すwiki 2.0

    Hiya, folks, and welcome to Week in Review (WiR), TechCrunch’s digest of the past week in tech news. It’s TC’s column that highlights the major stories over the past few days, and &#

    TechCrunch Japanese アーカイブ » SocialTextが目指すwiki 2.0
  • おれだったらフォト蔵APIをこうする(2) - ただのにっき (2006-03-02)

    ■ おれだったらフォト蔵APIをこうする(2) 昨日のエントリに対して、開発者の方からツッコミをいただいた。 Flickrにしろdel.icio.usにしろ来の意味でのRESTになってないAPIが多く存在するのが現実です。 これはagree。とは言ったもののFlickrやdel.icio.usのAPIは軽く眺めたことがある程度なので、コメントは控える。AmazonGoogleのような先駆的なベンダーがGETだけで済む取得系APIを公開して「これがRESTでござい」とやっちゃったのがいけなかったんじゃないかと、個人的には考えているのだが。 PUTやDELETEは開発者にとってもあまりなじみのない単語であり、GETやPOSTの方が分かりやすく、IEなどのwebブラウザだけでテストが行える利点があり、より多くの開発者を獲得できる可能性があります。 これもagree。たとえばRubyNet:

  • Plain Old XML / Plain Old ほげほげ - naoyaのはてなダイアリー

    Someone recently asked me about how to handle an internal product debate around REST vs. SOAP. In hopes I never have to address this debate again, here's a record of what I told them. Don Box が REST vs SOAP についての Pragmatics について語っている、という記事。この記事を読む前に OPC Diary: SOAP vs REST? いいから出荷しろ という記事をコメントまで含めて読んでおくと良い感じで消化できる、と思います。 で、あんまり記事とは関係ないお話で。POX - Plain Old XML という単語を恥ずかしながら初めて聞いたもので、そこに反応。 Plain Old

    Plain Old XML / Plain Old ほげほげ - naoyaのはてなダイアリー
    yukio2005
    yukio2005 2006/04/05
    何か複雑で新しいものを盲信するのは良くない
  • 私が“Web2.0 for Enterprise”を提唱した理由(2)

    図1 Web 2.0時代の企業情報システムにおけるクライアントのイメージ<br>社内外のマッシュアップ向けAPIなどを駆使して,様々なサービスをユーザーごとに専用の組み合せで提供する。専門性の高い情報は,他社がマッシュアップできるよう社外にも公開する。 (前回から続く)ここ数カ月間にわたり,Web 2.0という言葉は実に目覚しいスピードで日に広まりました。2005年末の時点で何人かの企業情報システム管理者に「Web 2.0をどう思う? 自分の仕事に関係あると思う?」と尋ねたときの反応は,以下のような調子でした。いわく,「Web 2.0? 全く関係ない!」,「個人情報保護,ISMS(Information Security Management System),日版SOX法など,セキュリティやコンプライアンスに必死に対応しているのに,怪しい/危ない技術で余計な手間をかけさせるつもりか?」

    私が“Web2.0 for Enterprise”を提唱した理由(2)
  • 私が“Web2.0 for Enterprise”を提唱した理由(1)

    Web 2.0という言葉が企業でささやかれるようになりました。社内でGoogleMapsを使ったり,さらに進んで「 マッシュアップ」されたWeb 2.0的アプリケーション(例えばこれ)を使ったりする人が増えてきたようです。システム・インテグレータや,目利きの鋭い情報システム部門の人も,Ajaxに代表されるリッチ・クライアントや,Blog/Wikiを活用したCMS (Contents Management System),Wikipediaのようなユーザー参加型サービスを気にし始めています。 「Ajaxという手法で構築されたWebアプリが軽快で便利らしい」「スタンドアロン・アプリケーション並みに高度なUIが簡単に実装できるらしい」「全社ナレッジ・マネジメントのためにブログを全面導入しよう!(これは経営者の科白ですね)」---こうした声が聞こえてきそうですね。いよいよ企業情報システムもWeb

    私が“Web2.0 for Enterprise”を提唱した理由(1)
  • RESTをWebサービスの定義に照らし合わせると・・・

    前々回,RESTとSOAPを対比して,リソースの呼び出しや連携の手順の違いを図解しました。そして前回,RESTの質を確認し,「RESTであればWeb 2.0だ」というのは誤りだと論じました。RESTというだけでは,Webの原点に強く回帰して「できる限りRESTに準拠した方がよい」という程度の,Web 2.0にとっての「緩い必要条件」と言えそうです。 その一方で,RESTに関心を持つ人が増えているのもまた事実です。前々回,Internet Magazine2006年4月号(インプレス発行)の記事「API公開ウェブサービスカタログ」に,各サービスのプロトコルがRESTかSOAPかが明記されていることを紹介しました。現在は,「REST準拠の連携の仕組みが新しい」という印象を与えていると言って間違いありません。 筆者も最近まで,SOAP/WSDLベースのWebサービスのことを「伝統的なWebサー

    RESTをWebサービスの定義に照らし合わせると・・・
  • プラットフォームとしてのWeb 2.0とRESTの関係

    前回,REST(REpresentational State Transfer)アーキテクチャ・スタイルに準拠した,新しい軽量なWebサービスが増えてきたことについて触れました。アーキテクチャ・スタイルとは,情報システムのプロトコルやデータ構造(情報構造)の基的性質を規定する“制約の束”のようなものです。今回は,このRESTについてもう少し説明しましょう。 RESTを既定する制約を挙げると以下のようになります。 (1)クライアント/サーバー型 (2)ステートレス(Stateless) (3)キャッシュを許可 (4)統一インターフェース(Uniform Interface) (5)階層化システム(Layered System) (6)コード・オン・デマンド(Code-on-Demand) (1)は,WebブラウザとWebサーバーで構成される,クライアント/サーバー型のネットワーク・アーキテ

    プラットフォームとしてのWeb 2.0とRESTの関係
  • RESTとSOAP:Web 2.0時代に意識され始めた2種類のWebサービス

    図1 RESTとSOAPの違い<br>図の左側に並んでいる角丸四角形はブラウザなどの情報/サービスの受け手を,右側の四角形はリソースやサービスを表す。RESTでは,リソースとその識別子であるURIが1対1に対応しており,URIを指定するだけで情報を取得できる。 初回にWeb 2.0の概念が急速に浸透していることをご紹介しましたが,Internet Magazineの素早さには改めて感心しました。2006年4月号の特集「マッシュアップ~Web2.0的サービス構築術」です。 38~41ページでは,「API公開ウェブサービスカタログ」と称して,マッシュアップの素材として使える公開サービスをカタログ化しています。42~47ページは,「マッシュアップショーケース」ということで,これらのAPIを使った,主立ったWebアプリケーションを紹介しています。海外のサービスには,Elicit(ブログの管理と情報

    RESTとSOAP:Web 2.0時代に意識され始めた2種類のWebサービス
  • OPC Diary: SOAP vs REST? いいから出荷しろ

    « AJAXが大事何ではないはず | メイン | "Crossbow", Windows Forms & WPF Interoperability » 2006年02月18日 SOAP vs REST? いいから出荷しろ Pragmatics - Don Box's Spoutlet ドン箱先生が、あんまりSOAPとRESTの違いについてあまりにも聞かれてウザイからと、その違いを5項目にまとめている。 SOAPを使用しているのか、POX(Plain Old XML)を使用しているのか。 一つはそれらのフォーマットにXML Schemaを使用しているか。 一つはXML Schemaを静的に言語にバインディングしているか。 一つがHTTPに特有の特徴に依存する程度。それは語られているように、危険覚悟でGETにねじどめする。 一つはメッセージ中心の設計アプローチをと

  • SOAP対RESTの戦い、ついに決着か - ZDNet.com SOAブログ

    SOAP対RESTの論争に、SOAPの開発者の1人であり技術書の著書も多数あるDon Boxが、最終的な白黒をつけた。この論争に火がついたのは、ちょうど去年の今頃だった。以下の要約は、開発協力者にAPIを提供しようと考えている人々に向けたものではあるが、SOAPが何に適していて、RESTが何に適しているかが端的にまとられている。 .NETおよびJava開発者にすぐれたエクスペリエンスを提供したい場合は、WSDLでスキーマを記述し、SOPAを適用する。 LAMP利用者を対象とする場合は、POX(Plain Old XML)メッセージをサポートし、フォーマットを非XMLスキーマ言語で記述して、RESTで提供する。 .NETおよびJava開発者とLAMP利用者の両方を相手にする場合は、SOAPとRESTの両方を用いる。 Boxは、「両方の開発層を競合社に先んじて取り込みたければ、宗教的な議論にふ

    SOAP対RESTの戦い、ついに決着か - ZDNet.com SOAブログ
  • Bridge Word

    This shop will be powered by Are you the store owner? Log in here

  • 1