ウェブサービスとクライアントコードのやおい妄想にはまってしまって、一人で萌えて転がり回った。身の回りにWebテクノロジーとやおい両方分かる人がいないから、話す相手がいないよー。 「先輩、悪いけど俺、頭悪いからSOAPとか分からないんですよ」 「そんな、僕はただ……」 「RESTで言ってくださいよ」 「POST...」 「405 Method Not Allowed。違うでしょう。Representational Stateが欲しいときはなんて言うんですか？」 「G.. GET /....待ってくれ……」 「400 Bad Request」 「なんでそんな。だから……」 「ほら、このインデックスは要らないんですか。このデータ無しで処理できるとでも思ってるんですか？」 「ち、違うんだ」 「だったらそんなエンプローブに包むような真似しないで、はっきり言ってくださいよ」 クライアントは「お客さん」
リソース指向なgeo+webのサブクラスの定義を試みます。 convivial-weblog さんから。 RESTfulは、リソース指向的な考えに基づいたアーキテクチャなので、何かしらの処理を関数的に実行させたい場合などは、RPC（Remote Procedure Call）的に呼び出せる「なんちゃってREST」の方が適しているケースも多いように思います。 http://convivial-web.com/blog/2009/03/restrestful.html 関数的に呼び出す形のものはやはり RPC 的にしておくのがよさそうだと思っています。OGC の規格でよくある、引き出し対象を任意の矩形で指定するようなパターンは、典型的に RPC 的なパターンであると考えており、あのパターンを RESTful にすることは至難だと思います。 geo+web の特徴の分析から、そのような RPC
いやその特段仕事で経験値を積んだわけでもなくなんといいますか技能低下防止にとそこらのＩＴ系ブロガーのＲＳＳ眺めているだけなんですが、地理情報業界でＲＥＳＴ対ＳＯＡＰといった話が出てきて arton さんまで引用しているとはただならないものを感じるのであります。 要するにまだ話題自体よくわからんのだけど、2005年頃OGCがISOと結託してXMLベースのクソ分厚いプロトコル群にまとめ始めたのと同じくらいのエポックみたい。 とりあえず、話にまとめる時間を天が許すとは思えないので、わかったことだけ。 SOAP が勢力を築いてきた地理情報の世界に REST(ful) が勝ちという世間の潮流がなだれこんできたようだ。よくわからんが simple is the best という我が信念からすれば神は偉大なりと唱えるところであろう。 ここ数年欧州ががんばってINSPIREというものをつくっていて、止せば
d:id:hfu:20090308:1236457561 *1に方向性の異なる反応をいただけてありがたいです。 convividal さんには「日本でも REST で決着ついてるよ」的な反応をはてなブックマークでいただきました。 arton さんには「まだ決着ついてないけど REST でも SOAP でもどっちでもいいよ」的な反応を http://arton.no-ip.info/diary/20090309.html#p03 経由でいただきました。 ありがとうございます。たぶん REST だとか RESTful という単語自体が曖昧さと難解さを含んでいることもあり、応用分野ごとの違いもあり、このような多様な反応を得ることができたのだと思います。 私は、 地図系で支配的な用途については、SOAP とその仲間たちが提供する機能は必要ないよ。（なので、用途には不要な機能を非常に多く、普及する前
欧州にとって痛恨なのは、INSPIRE が SOAP 漬けになっていること。INSPIRE の主要目的のためには SOAP で良いのかも知れないのですが、次のステップでは重荷になるでしょう。 d:id:hfu:20090304 のような話の続きを、誰かが日本語で書かなければならない気がとてもしています*1。ただ、英語では日常的にこの話題は出現しています。例えば3月6日にも次のような記事が出ています。 SOAP をやめることは驚くべきことではない Of course this is not surprising in the least bit, but Google is abandoning their SOAP API to focus on their RESTful APIs. Most developers, myself included, prefer working wit
_ 遅ればせながらUKアマゾンで買い物 ピーターラビットの本が欲しいと子供にねだられた。 まあ、スタンダードだから（10年遅い気もするが）いいかなぁと思いながら、いったい、日本語と英語どっちが欲しいんだ？ と訊くと、両方とか答えやがる。 で、ふとUKアマゾンが安いと（もうずいぶん遅れたからそうでもないことになっているみたいだが）思い出したので、ちょっと探してみる。が、まずは、あわてず日本のアマゾンで見ておく。 The World of Peter Rabbit Gift Box 1-12(Potter, Beatrix) $84が7354円か……というか、これは米ドルで書いてあるが、日本で買ったほうが送料かからない分、安いかも。 と思って良く見ると、ボックスが小さい。で下に、13巻以降のもあった。 The World of Peter Rabbit: The Original Tales
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
正直、中島聡さんともあろう人がこんなエントリーを書くなんて。 SOAPは必要で使いやすい場面もあれば必要もない場面もある。JSONだって使いやすい場面と使いにくい場面がそれぞれたくさんある。 "Hello World"という一文を表示するプログラムを書くとき、JavaやC#は行数が増えてしまう。じゃぁLLだけでいいよね？といってるのと同じ。くだらない。 おいらがApacheSOAPで昔実装したときはXMLを扱うパフォーマンスも遅かったし、XPathも標準で扱えなかったりと結構大変だった。ベースがXML-RPCということで非常にシンプルな実装だった。プリミティブな引数と戻り値を使う場合何も難しいことはなかった。シンプルさで言えばXML-RPCのほうが上だったが、面倒な記述をすることによってクラスのインスタンスを丸ごと送ることは一応出来た。あくまでも面倒な記述はオプションであって必須ではなかっ
GET /WebSite1/WebService.asmx/getHello?str=string HTTP/1.1 Host: localhost HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <string xmlns="http://tempuri.org/">string</string> RESTは、WebブラウザのAjaxや、クライアントアプリから使う場合もあるが、サーバ間のシステム連携でも使う。 RESTの最大の特徴は「WebブラウザにURLを入力すれば動作確認できる」事である。 Webブラウザで容易に動作確認ができるため、すでに存在しているサービスに対しては「まずはアクセスしてみて必要な情報
Strange spate of discussion recently about XML vs. JSON. On M. David Peterson's Weblog he states what I think is the obvious: there is no serious battle between XML and JSON. They're entirely complementary. Mike Champion responds: The same quite rational response could be given about the "war" between WS-* and REST, but that has caused quintillions of electrons to change state in vain for the last
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
