RESTアンチパターン
多くの人々にとって、RESTは単純にあるアプリケーションの機能を公開するためにHTTPを使用することを意味します。基本的で最も重要なオペレーション (厳密に言えば、「動詞」や「メソッド」がより良い表現です)は、HTTPのGETです。GETはURIによって特定されるリソース表現が必要です。しかし、多くの場合、それがすべてではないとしても、既存のHTTPライブラリやサーバープログラミングAPIは、リソースの識別子としてではなくパラメータをエンコードするための便利な手段として見ることがとても多いです。結果、以下のようなURLとなります。: http://example.com/some-api?method=deleteCustomer&id=1234 実際、URLを作る人は、与えられたシステムの「RESTful具合」について何も言いません。しかし、私たちは特定の場合においてGETが「安全」では
REST vs SOAP
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ブラウザで容易に動作確認ができるため、すでに存在しているサービスに対しては「まずはアクセスしてみて必要な情報
yohei-y:weblog: REST ってやっぱり難しいかも。
前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。
ただのにっき (2006-03-01) - おれだったらフォト蔵APIをこうする
■ Apple新製品 iPod Hi-Fi、ダセぇ。これがApple製品だなんて信じらんない。他社製品が間違って紛れ込んだんじゃないのか。 Mac miniは、相変わらずちょっと欲しい。やはり小さい機械には惹かれる。これでWindowsが動けばなぁ(←だいなし)。 ■ おれだったらフォト蔵APIをこうする せっかくユーザでもあるので(携帯のバックアップにしか使ってないけど)、β公開されたフォト蔵API(アナウンス)を使ってみることにした……んだけど、概要を読んで「ちょっと待て」と思った。 フォト蔵APIは全てRESTで提供されています。機能毎の個別のURLに対して必要なデータをPOSTします。結果は全てXMLで返ってきます。 えーと、GETを使うべきAPIでもPOSTですかね。それ、RESTじゃなくてただの「なんちゃってRPC」だし。……とは言ったものの、自分だってRESTを理解しているか
Tender Surrender » OpenSocial/RESTful API Specification
RESTful APIはすべてのOpenSocial 0.8に対応したクライアントおよびサーバーに共通のプロトコルとして提供されます。これは2007年11月に発表されたGDataベースのOpenSocial data APIを置き換えるものです。 概要 † このAPIはクライアントがウェブページ上のガジェット外部にあるOpenSocialコンテナサーバーとやり取りするための、言語にもプラットフォームにも中立なプロトコルを定義します。プロトコルとしては、どんな言語でも、どんなプラットフォームでも比較的容易に実装可能なように作られています。この仕様は、ウェブページ上のガジェットから、ユーザーデータの同期を行うサーバーまで、様々なクライアントから利用することができます。 このプロトコルは主に、リソースとそのオペレーションについて扱い、HTTPプロトコル上でサーバーから取得や更新を行う標準のHTT
クリックジャッキングの本質的な解決策 - IT戦記
誰か書いてそうだけど、気にせずに投下 現実的な解決策ではなくて、本質的な解決策 クリックジャッキングはそもそも CSS の問題なので CSS の枠組みで解決すればいい。 CSS での解決策 具体的には、以下のルールをユーザースタイルシートに追加すればいい。 * { opacity: 1 !important } CSS2, CSS2.1, CSS3 では、ユーザースタイルシートの !important な宣言は他のどの宣言よりも優先されるはずなので、ちゃんと仕様を満たしているブラウザを使っていれば問題ないはず。 （IE の場合は、 opacity じゃなくて filter を。。というか、オプションで何か filter とか無効に出来た気がするけど、忘れた＞＜） ユーザースタイルシートは、 IE, Firefox, Opera, Safari ほとんどのブラウザで使うことができる。 あと、
iPhoneの本質 Androidの真価 - MIRAI THE FUTURE
Androidが気になっていたので、読みました。昨年実施されたイベントのセッションをまとめた一冊です。覚えておきたいことをメモ的にまとめ。--■各社のプラットフォームGoogleAppleMicrosoftNokiaクラウドGoogle ServiceMobile MeLiveOviコネクティビティAndroidiPhoneWindows MobileSymbianクライアントWebkitWebkitInternet ExplorerWebkitアプリ流通Android MarketAppStore??音楽ストアAmazoniTunesZune MarketplaceOvi開発言語JavaObjective-C.NETC/C++,Javaこれからは、iPhone（独自） VS その他（オープン）という構図。ドコモも参加している、LiMo（携帯電話事業者やメーカーが推進するプラットフォーム）
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
なぜ地域SNSは「立ち枯れる」のか インターネット-最新ニュース:IT-PLUS
http://iphone-rejectdb.appspot.com/