タグ

restに関するsatoshipのブックマーク (19)

  • サービスのread/writeとコンテンツのfav - bits and bytes

    Permalinkという概念が浸透して、比較的最近作られたようなウェブのサービス上にあるリソースには、そのリソースを一意に表すことのできるURLが割り当てられているようになりました。このブログの記事を表すURLはhttp://labs.gmo.jp/blog/ku/2008/06/fav.htmlで、このURLにアクセスすればこのページがなくなったりしない限りは"多くのサービスに見られるコンテンツに対するfavという概念"について書かれた文章が得られます。このブログにある記事が増えたり減ったりしても、この記事を表すURLは変わりません。 read/write ひとつのリソースに普遍的なひとつのURLが割り当てられていれば、そのURL自体をIDにしてリソースを読み書きすることができます。以前デバイスドライバ/FUSEのrestfs/SITEINFOの役割比較で触れたRESTfsはその前提の上

  • PUT and DELETE with jQuery // homework prod.

    I became a big fan of REST. Especially articles and code by Joe Gregorio, mainly his "How to create a REST Protocol", were a great help to me. Together with AJAX, it allows me to create clean APIs for my web applications and paves the way for user interfaces with more interaction as they are known from the desktop. It comes with a price tag, of course, and that says "JavaScript dependency". My fir

  • scaffold_resourceでREST fullなRailsアプリ(1):TKMR.blog.show

    Rails1.2から入ったscaffold_resourceを試してみる。まずごく単純に ruby script/generate scaffold_resource Hoge title:string titleフィールドのみを持つHogeリソースを作る、でrake migrateして完了!アクセスしてみる irb(main):002:0* require 'net/http' irb(main):003:0> http = Net::HTTP.start('localhost',3000) irb(main):005:0> p http.get('/hoges.xml').body <?xml version="1.0" encoding="UTF-8"?> <nil-classes></nil-classes> hogesにGETのアクセスでindex irb(ma

  • RESTfulなWebサービスは、WebAPIを提供していないのか - winplusの日記

    masuidrive on rails さんの記事で、RESTに関して疑問をもたれているものがありました。何が問題なのかうまく理解できていませんので、まったく勘違いしているかもしれませんが、RESTful Webサービスを読んできての練習問題として。 まずレスポンスコードでステータスを判断するとFreeSpotとかで問題にならない? – @masuidrive blogから。 Railsだけを考えるなら、サービス全体をRESTfulにして、HTML以外にXMLも返す様にしておけば、外部から使うのも比較的容易......ただ、Rails以外でクライアントを作るのがメンドクサイ。 WEBサービスとはプラグラムが利用するわけで、当然そのクライアント・プラグラムを作成する必要があるということ。で、そのクライアント・プラグラムは、WEBサービスがどんなフレームワークで動作しているかとは(少なくとも原

    RESTfulなWebサービスは、WebAPIを提供していないのか - winplusの日記
  • restful-reading

    USTREAM restful-reading : .

  • yohei-y:weblog: RESTful Web サービスの読みどころ: はじめに

    すでにオライリージャパンのサイトやメールニュースで新刊情報が流れていますが、 以前から何回か紹介してきた RESTful Web Services の翻訳版の監修をさせてもらいました。 すでにさまざまなブックマークサイトで好意的に言及していただいており、とても光栄です。 まだ amazon には掲載されていませんが、12月19日か20日には都内主要書店に並ぶそうです。 追記(2007-12-08) 掲載されました RESTful Web サービスLeonard Richardson Sam Ruby 陽平 株式会社クイープオライリー・ジャパン 2007-12-21 そこで、今回から何回かにわたって、発売記念でこのの「読みどころ」を紹介したいと思います。 今回は初回なので、僕が書いた監訳者まえがきから少し引用して、書全体の読みどころを紹介します。 書 「RESTful Web サ

  • t-wadaの日記 - 書評: RESTful Webサービス

    RESTful Webサービス 作者: Leonard Richardson,Sam Ruby,山陽平,株式会社クイープ出版社/メーカー: オライリー・ジャパン発売日: 2007/12/21メディア: 単行購入: 25人 クリック: 842回この商品を含むブログ (168件) を見る このの監訳をされたyoheiさんから献していただきました。ありがとうございます。 実はまだ邦訳版を読み終えてはいないのですが、原書は結構読んだつもりです。献していただいたお礼を兼ねて、このの紹介をさせていただきます。 このの意義 私はこのの意義は以下の点だと考えています。 Web上に散在しているRESTに関する情報を、として一つの形にまとめたこと RESTfulなシステムの「設計方法」について正面から議論されていること 設計方法だけでなく、実装方法、実装時のトレードオフにも踏み込んでいること

    t-wadaの日記 - 書評: RESTful Webサービス
  • 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メソッドを使ってデータを授受する事も

    MOONGIFT: » RESTfulなWeb APIを使う開発者は必須「eXeve」:オープンソースを毎日紹介
  • RESTなRails向けのJavaScriptライブラリ Jester まとめ:TKMR.blog.show

    昨日のエントリJesterについて補足。 Jester.jsソースを見ると当にシンプルで、まだ欲しい機能もありそうなので一通りまとめてみた。 基的な登場人物はBaseクラス (prototype) だけ、あとXML.ObjTreというライブラリを使用してXML → DOM → XMLの変換を行ってるみたい。このライブラリ何気に日人が作者なんだね、初めて知った。 以下まとめ 主なメソッド Base.model(モデル名, サーバURL, 単数形の名前, 複数形の名前) modelクラスの宣言。もしモデル名がBookなどで、単数形book & 複数形books のように単純な変化なら暗黙的に行ってくれる。 Base.model("Book") でOK。 例;Base.model("Book"); Base.find(目的のID) モデル名Book & 引数のidが1だとすれば http:

  • yohei-y:weblog: REST の勝利宣言と良い XML の見分け方

    ITpro Challenge 行ってきました。 豪華なメンバーでどの講演もとても面白かったですね。 江島さんの講演は、Web 上でサービスをやるとはどういうことなのかについてとても示唆に富んだ話だったし、 鵜飼さんのハッカーのソフト工学の話は職場的にすげータイムリーだったし、 なおやさんの話は同時代を生きてきた、生きている者としてとても共感できる内容だったし、 戀塚さんはこれぞハッカーという感じのすごい人でした。 僕は LT の最後に話をさせてもらったわけですが、 ネタを二つ持っていって聴衆のみなさんに選んでもらうことにしました。 結果は REST が勝ったので、当初の予告どおり REST の話をすることに。 結局お蔵入りになった XML の話ですが、もったいなかったので懇親会でお話させてもらいました。 プレゼン中で引用した Web ページはこちらです。 檜山さんの記事 XML ボキャブ

    satoship
    satoship 2007/09/10
    "REST 萌え!!" / FUC = 不安(Fear)、不確実(Uncertainty)、不信(Doubt)の頭文字をとった単語。
  • Rest 2 - ウィザシステム - Witha System Ltd.

    HepCat Dev and Test Blogクライアント『BlogWrite』の開発&テスト&アップデート情報をメインに、ブログやWebにまつわる技術的トレンドなどを扱う開発ブログです。 [ Atom/REST ] RESTfullなAPIにおいてのエラーハンドリングについては重要なのですが、今まで(特に日では知っている限り)あまり言及されたことがなさそうなのと、オライリー系のサイトでたまたま今日良い記事 RESTful Error Handling を見つけたので、ココで紹介したいと思います。 (2003年12月の記事ですが何故か見落としていました) この記事では、REPSfullなWebアプリケーションにおいて、エラーが発生した時の動作は(調査した所)一般的にいって4っつの方法が利用されているとしています。 1.HTTPステータスコードのみ 例えば、 http://www.exa

  • 第八回 XML開発者の日 - 2nd life (移転しました)

    でRESTful Wikiな実装、という題目で発表してきました。長時間のプレゼンが初めてだったり、緊張しまくって「なんかなんか」云いまくってました。あとおもいっきり実装に偏った話で聴衆置いてきぼり、とかいろいろと…。今回の反省点をふまえて、次回のプレゼンに生かそうと思います。 内容は他の方々が詳細な感想などを書かれてるのでそちらを参考に。たぶん発表者の中じゃ一番RESTの知識が少なかったので、他の方々の発表は大変刺激的で、参考になりました。 発表資料は以下の場所に置いておくので、良かったらどうぞ。 http://rails2u.com/tmp/ppt/rest051124.ppt

    第八回 XML開発者の日 - 2nd life (移転しました)
  • RESTWiki - 2nd life (移転しました)

    http://rails2u.com:8008/ REST APIを使い、表示、新規作成、編集、削除を行えるwikiを作ってみた。とは云うのも、先日のPofEAA読書会の時に高橋メソッドの高橋さんとRailsでREST実現するには、という話をしていて気になったのでさくっと実装。 http://rails2u.com:8008/rest/名前 というURIに対してHTTPのGET,POST,PUT,DELETEメソッドを送ると表示、作成、編集、削除するという簡単な機能の物を作ったんだけど、それだけじゃつまらないんでフロントエンドとしてxmlhttprequestを使って各種操作が行えるインターフェイスも付けてWikiっぽくした。 RailsでのREST実装は最初、僕らにはコレ系のwebservice apiを簡単に扱えるActionWebService(railsの主要ライブラリの一つ)があ

    RESTWiki - 2nd life (移転しました)
  • scaffold_resourceでREST fullなRailsアプリ(1):TKMR.blog.show

    Rails1.2から入ったscaffold_resourceを試してみる。まずごく単純に ruby script/generate scaffold_resource Hoge title:string titleフィールドのみを持つHogeリソースを作る、でrake migrateして完了!アクセスしてみる irb(main):002:0* require 'net/http' irb(main):003:0> http = Net::HTTP.start('localhost',3000) irb(main):005:0> p http.get('/hoges.xml').body <?xml version="1.0" encoding="UTF-8"?> <nil-classes></nil-classes> hogesにGETのアクセスでindex irb(ma

  • 今更ながらRails1.2の変更点とか翻訳してみた:TKMR.blog.show

    Rails1.2も出たことだし、変更点とかちゃんと読んどこうと思ってざっくり訳してみた。やっぱ り:format&respond_toとscaffold_resourcesでRESTFull化が目玉っぽい、あとマルチバイト対応が日人的には嬉しいかも。 原文: Riding Rails: Rails 1.2: REST admiration, HTTP lovefest, and UTF-8 celebrations REST and Resources RESTはRails1.2の目玉です、RESTに関しては私(DHH)のRailsConfキーノートを見てください。REST化はRailsのために重要な物です。あなたのアプリケーションをよりRESTfullにするための方法を考え始めてください。 REST化への移行を手伝うために、私達はCRUDなインターフェイスを作るためのsca

  • tinsep19のブックマーク / 2006年6月15日 - はてなブックマーク

    録音・録画補償金やDRMのあり方など、著作物の意義や対価システムが見直されようとしている。消費者にしてみれば、もちろん補償金もDRMもいやだということだけははっきりしているわけだが、権利者の団体はそれによって著作権者の利益が守られるのだと主張する。 だがちょっと待って欲しい。権利者といっても、いつも議論の舞台に登場するのはJASRACを始めとする権利団体だ。当の意味での著作権者である音楽家達は、補償金やDRMなどのことをどう考えているのかという話は、ちっとも伝わってこないのである。 これはどう考えても、議論の席に座る人のバランスとしておかしいだろう。その権利者団体が、果たして正しくミュージシャンなど芸術家の総意を代表していると言えるのかがはっきりしないことには、権利者団体と話し合いをして意味があるのかも、実はわからないのではないか。 実際のプロの音楽家が今日の状況をどのように考えているの

    satoship
    satoship 2007/08/02
    "でもそれならDBがHTTPサーバーを持てば、アプリでは何も実装しないでもよくなるのではないだろうか。"
  • RoR Wiki 翻訳 Wiki - RubyKaigi2006

    最近オープンしたエミナルクリニックの徳島院がめっちゃ気になるなぁ。 医療脱毛なのにすごい安くていい評判も聞くけど、ほんとに痛くないのかな? 通っている人の口コミをみてみたいなぁー。 なんて気になったので、エミナルクリニックの徳島院についてSNSやネットで調べてみました。 そう思ってSNSを中心に調べてみたら、、、口コミや評判も良いじゃない♪ ちなみに、似たようなサービスや商品があるかも?なので、今回調べてみたのはこちらになります。 オープンしました! エミナルクリニックの徳島院ですが、すでにオープンしています!(2021年4月9日オープン済) もちろんですが、オープンしたてなんでめっちゃ予約が取りやすいです。 ただし!!人気のある医療脱毛院なので早めの予約が良いかも?!

  • yohei-y:weblog: REST 入門

    語の REST のリソース集を以前作ったのだが、 日語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は

  • 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

  • 1