t-wadaの日記 - 書評: RESTful Webサービス
RESTful Webサービス 作者: Leonard Richardson,Sam Ruby,山本陽平,株式会社クイープ出版社/メーカー: オライリー・ジャパン発売日: 2007/12/21メディア: 単行本購入: 25人 クリック: 842回この商品を含むブログ (168件) を見る この本の監訳をされたyoheiさんから献本していただきました。ありがとうございます。 実はまだ邦訳版を読み終えてはいないのですが、原書は結構読んだつもりです。献本していただいたお礼を兼ねて、この本の紹介をさせていただきます。 この本の意義 私はこの本の意義は以下の点だと考えています。 Web上に散在しているRESTに関する情報を、本として一つの形にまとめたこと RESTfulなシステムの「設計方法」について正面から議論されていること 設計方法だけでなく、実装方法、実装時のトレードオフにも踏み込んでいること
Index - ウィザシステム - Witha System Ltd.
AtomPub Test Client – code name “Fude” – beta Fude (コードネーム) は The Atom Publishing Protocolの開発支援及び相互運用性テスト用のツールです。 TODO: ファイル拡張子 <=> MIME/Media-Typeのマッピング。 他多数 動作要件 Windows 98SE/ME/NT4/2000/XP/Vista (日本語版または英語版) Internet Explorer 6以上 Download fude.zip Zipファイルを解凍すると、実行ファイルが入っています。レジストリは触りません。アンインストールはファイルの削除です。エントリなどのローカルキャッシュは”C:\Documents and Settings\YOUR-LOGON-NAME\Application Data\witha\Fude”に保
Implementing RESTful Web Services in Java - JavaでのRESTful Webサービス(JSR-311)実装「Jersey」の技術TIPS
JavaでのRESTfulウェブサービス(JSR-311)実装のJersey(https://jersey.dev.java.net/)の技術TIPS。 JAX-RS と Jersey JAX-RSは、JavaでRESTfulウェブサービスを構築するための標準化された annotationやインターフェースAPIを提供します。 まだ完全なものではないようですが最終系は、Java EE 6の一部になるようです。 JAX-RSの詳細な情報は、jsr311 project(https://jsr311.dev.java.net/)で得る事ができます。 Jerseyプロジェクトからダウンロードすると、いくつかのサンプルが見れます。 技術TIPSで見たのは、Bookmark Application。 データがJSON。 JAX-RS APIを使い以下のようなJSONデータを返します（ブックマーク保存
[B! tagmobile] wackyのブックマーク
キーボードショートカット一覧 j次のブックマーク k前のブックマーク lあとで読む eコメント一覧を開く oページを開く ✕
クールなURIは変わらない -- Style Guide for Online Hypertext
クールなURIとは？ クールなURIとは変わらないもののこと。 どんなURIが変わってしまう？ URIは変わらない：人がそれを変更するのだ。 理屈の上では、人々がURIを変更するべき（もしくはドキュメントのメンテナンスをやめてしまう）理由は全くありません。しかし、現実には山ほど理由があります。 理論上では、ドメイン名空間の所有者はその空間を所有しており、したがってその中に含まれるURIも所有権を持ちます。ドメイン維持料が支払えない場合を除いて、その名前を保有し続けることを妨げるものはありません。そして理論上は、あなたのドメイン名のもとにあるURIは、完全にあなたの管理下にあり、望む限りそれを安定的に保つことができるのです。 ウェブからあるドキュメントが消えてしまう唯一の納得できる理由は、そのドメイン名を保持していた会社が廃業してしまうか、サーバーを維持できなくなったという場合ぐらいでしょう
技術者視点のユーザビリティ考 第22回 “使いやすいURI（URL）”の設計 -- ページをリソースとして考える：ITpro
前回，前々回と使いやすいURIの設計のポイントについて見てきました。今回も引き続き，使いやすいURIにするにはどうしたらいいのか，ということについて考えていきます。 URIの使いやすさについては，いろいろと考える話題が多いのですが，ここで話題として取り上げるのは「ページをリソースとして考える」ということについてです。リソースとは，そのまま日本語に訳せば「資源」という意味になります。 リソースという言葉はいろいろなところで使われています。例えば「これだけの仕事をこなすにはチームのリソースが足りません」といったときには，人的資源というか，そのチームが持っている作業可能量のようなものを意味しています。コンピュータのリソースといえば，処理を行うために必要なメモリー量とかCPUパワーとか，もしくはネットワークの帯域などもリソースと呼ばれます。 これらの例を見ると，リソースは「限りある資源」という感じ
yohei-y:weblog: REST の日本語リソース
日本で REST がぜんぜん盛り上がっていないようなので、日本語で読める REST のリソースをまとめてみた。 東大市山氏による Roy Fielding の論文紹介。技術的な要素を理解したいけど RoyF のドク論を読むのは厳しい人にはお勧め。 http://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports/pdmwa 元論文はこれのようだ Principled Design of the Modern Web Architecture http://www.ics.uci.edu/~taylor/documents/2002-REST-TOIT.pdf 同氏による REST 版ショッピングカートの実装例。こちらも参考になる。 http://kumiki.c.u-tokyo.ac.jp/~ichiyama/projects/reports
RESTなWebサービスをマウントするRESTファイルシステム、FUSEで作ってみた:TKMR.blog.show
RESTなWebサービスをマウントするRESTファイルシステム、FUSEで作ってみた FUSE REST Ruby 2007-06-24 FUSE用のRubyライブラリで、FuseFSてのがあるのを最近知った RubyのFuseFS使ってtwitter file systemを作ってみた Rubyで手軽にファイルシステムを構築できるそうな。面白そうなので、ひとつ試しにRESTなWebサービスをローカルにマウントするRESTファイルシステムを作ってみた。 （http://localhost:3000/books/3.xml へアクセスして中身を表示） あと外部Webサービスをローカルにマウント！てのがやりたかったので、TwitterとTumblrのAPIをマウントしてみた。 $ cat ~/restfs/TwitterStatus/user_timeline/117011742/t
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
MOONGIFT: » RESTfulなWeb APIを使う開発者は必須「eXeve」:オープンソースを毎日紹介
Memotuneでは現在、Web APIを開発している。GDataに準拠しているので、Web APIの形式はRESTfulだ。ただ、RESTfulは最近の流行とは言え、問題がない訳ではない。 最大の問題はテスト環境だ。PUTやDELETEといったHTTPメソッドを手軽に試せない。IEやFirefoxは対応しているようだが、おそらく手軽には試せないだろう。 そこで専用のクライアントを使うのが良い。RESTfulに限らず、XMLを経由したMashup開発者は必須ではないだろうか。 今回紹介するフリーウェアはeXeve、RESTfulなWebアプリケーション開発ユーティリティだ。 eXeveを使うとWeb APIとやり取りするXMLが簡単に作成できる。構造チェックやDTDによる検証ができればよけいなミスも減るはずだ。 また、PUTやDELETEといったHTTPメソッドを使ってデータを授受する事も
＠IT：Opinion -- 吉松 史彰：Webの「正しい」アーキテクチャ
ブラウザとWebサーバの組み合わせで作られる、いわゆるWebアプリケーションの開発が盛んだ。それまでのクライアント／サーバ・システムにおいて悩みの種だった新バージョンの配布や保守の問題が解決され、システム管理者が楽になったのが理由であるといわれている。しかし、クライアント／サーバ・システムを開発していた開発者にとっては、Webは非常にシステムを作りにくい環境だった。貧弱な機能しか持たないブラウザと、単純なデータしか送信できないプロトコルを利用して、これまでどおりのLook and Feelのアプリケーションを作れというのだ。どだい無理な話である。 だが、開発者には味方がいた。開発ツール・ベンダである。開発ツール・ベンダは、Webアプリケーション開発者が悩んでいるのをビジネス・チャンスと考えた。その結果、さまざまなWebアプリケーションの開発環境が作られた。それらすべての開発環境に共通してい
Ruby on Rails/第11回勉強会 - RESTful Rails Development
RESTful Rails † HTTPはGETやPOSTメソッドだけでなく、PUT, DELETEメソッドもある RESTとは、簡単にいうとHTTPのGET, POSTだけでなく, PUT, DELETEを使ったやり方である Rails 1.2ではRESTがサポートされた このチュートリアルはRESTのコンセプトと背景の短い紹介からはじまる RailsのScaffoldを使うと見ることができるREST-Controllerとmodelは、RESTful Railsの開発の理解を助けてくれる 次にREST Routingとよばれる機能の説明をする。 Nested Resourcesの章はより上級な内容で、どのようにREST-URLのコンセプトに反せずに、親子関係にあるリソースがネストされるかについて説明する このチュートリアルの終わりは、RESTとAJAXについての説明だ RESTfulな
yohei-y:weblog: HTTP ステータスコードを正しく使おう
先月、ぐるなび API がリリースされていました。 ぐるなびさんの持っている膨大なデータベースに Web API を通して気軽にア クセスできるようになったのは、非常に喜ばしいし、その英断に感謝したいと 思います。 しかし、Web API 仕様書、特にエラー仕様を見てちょっとがっかりしました。 もう少し上手にデザインすれば、もっとよかったのに…、という思いです。 一度出してしまった API はそう簡単に変えられないと思いますが、 参考までに僕だったらどうするか、を書いてみます。 この仕様の一番の問題はエラーコードです。 以下は 2-2 のエラー仕様に記述されているサンプルです。 <?xml version="1.0" encoding="UTF-8"?> <gnavi> <error> <code>602</code> </error> </gnavi> タグが三つ(gnavi, erro
解説 Atomとは何か: RSSやXML-RPCとの比較、そしてAtomAPIの使い方まで
技術評論社「Software Design」2005年1月号 第2特集「次世代Webテクノロジ：Atom基礎講座」に寄稿した、The Atom Publishing Protocol (The Atom API)、The Atom Syndication Format の総合的解説です。 Witha System » Atom目次 » [1章 The Atom Project – RSSの興隆からAtomの誕生] » [2章 Atomフォーマット – The Atom Syndication Format] » [3章 Atom出版プロトコル – The Atom Publishing Protocol(AtomAPI)] » [4章 The Atom Publishing Protocol（AtomAPI）の利用法] » [AtomやAtomAPI関連のニュースや仕様へのリンク] » [
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon Web サービス入門(Product Advertising API)
インタビュー：Jérome Louvel氏にRestletについて聞く
はてな
サービス終了のお知らせ