![Amazon.co.jp: RESTful Webサービス: Leonard Richardson (著), Sam Ruby (著), 山本陽平 (監修), 山本陽平 (読み手), 株式会社クイープ (翻訳): 本](https://cdn-ak-scissors.b.st-hatena.com/image/square/14e0814be5e53ce744e63a44a44b98a5a74de08d/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F51Su2Ger2sL._SL500_.jpg)
Restletとは? Restlet(http://www.restlet.org/)は、Web APIなどで主流となっているREST(REpresentational State Transfer)型の通信を行うアプリケーションを構築する「軽量な(Lightweight)」Javaフレームワークです。CDDL1.0とGPL2.0のデュアルライセンスの下で配布されています。開発はフランスのNoelios Consulting社(http://www.noelios.com/:フランス語)が主体となって行っています。バージョン1.0.1がリリースされたのは2007年5月3日です。 JavaのREST APIといえば、JAX-RS(JSR 311)の仕様をJCPで詰めている最中ですが、Restletではバージョン2.0のAPIをJCPに提出することを計画しています(2007年4月25日付のNo
Web APIの乱立とAtom 現在、一般コンシューマ向けのWebサービスは多くのサイトがネットワーク越しに利用できるAPI(Application Programmable Interface)を公開しています。いわゆるWeb APIと呼ばれるものです。開発者向け技術雑誌などを見ても、マッシュアップやAPIプログラミングの解説記事が多く掲載されるようになりました。 2000年代の前半からGoogleやAmazonをはじめとした主要なWebサービスがAPIを公開し始めました。2000年代中盤からは様々なサイトでAPIが公開されるようになり、現在に至っています。当初はWebで人間がアクセスできる情報をAPIとして公開していましたが、現在ではWebブラウザで情報提供はしないもののAPIだけ提供するというサイトも増えてきました。 さて、これらのWeb APIアーキテクチャを見てみると、現状では各
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
先月末にRESTful#とは勉強会2を開催してきました。 これがもう!!!!本当に良かった!!!!勉強になった!!!まだ興奮冷めやらぬ感じです。 勉強会1回目が終わり、得たRESTの知識を私はすぐ実践に生かすことが出来ました。 「これはURLとアクション考えるとControllerもう1個用意する?」なんて会話も出るようになり、レベルアップした感があります。 2回目はどうしようかなとぼんやりしていた時に見た このスライドが大変興味深くて、他にもSlideShareのREST関係も徘徊しましたが、これが一番鷲掴みされました!!! (レベルが上がってからまた徘徊すると、他の難しいと感じたものにも鷲掴みされるのかもしれませんね。楽しみ。) 「これは皆読むべき!そしてちゃんと理解できるようになりたい!」と思い、「WEBを支える技術」を見返したところ、最後の5部が「WEBサービスの設計」でしたので、
Web API: The Good Parts 作者: 水野貴明出版社/メーカー: オライリージャパン発売日: 2014/11/21メディア: 大型本この商品を含むブログ (1件) を見る 業務ではiOSアプリとバックエンドの開発を両方担当しているので、APIの設計を何回かやってきた。しかし、自分なりのやり方でやってきた部分が多かったので、最近発売されたWeb API: The Good Partsを読んでちゃんとした設計について学ぶことにした。 得られた学びをメモとして残す。 HATEOAS HATEOAS(Hypermedia As The Engine Of Application State)という設計方法を初めて知った。HATEOASではまず、サーバー側はレスポンスに関連するエンドポイントを含め次にアクセスするAPIを簡単に辿れるようにする。クライアント側は最初のエンドポイント以
技術部の小野(@taiki45)です。この記事では簡単なアプリケーション(ブログシステム)の実装を通して、クックパッドで作成・使用しているライブラリのGarage の紹介と Garage を使った RESTful Web API の開発をご紹介したいと思います。 Garage は RESTful Web API を開発するための、 Rails gemified plugins です。Rails プログラマは Garage を使って Rails を拡張することで素早く Web API を開発することができます。Garage は新しくアプリケーションを開発する場合にも、既存の Rails アプリケーションに組み込んで Web API を実装する場合でも使用できます。Garage はリソースのシリアライズやアクセスコントロールなど Web API の実装に必要な機能をカバーしています。 Ruby
第12回おわりに:RESTがつくる明るい未来 山本陽平,羽生章洋,和田卓人 2008-01-28
本書は、RESTというWebのアーキテクチャスタイルについて解説する初めての本格的な書籍である。RESTFulなアーキテクチャの概念、RESTfulなサービスの特徴について述べ、RESTful Webサービスを設計するための基本的なルールであるリソース指向アーキテクチャについて解説する。現実のRESTfulなサービス、AmazonのS3、AtomPub、地図アプリケーションなどを例に挙げ、さらに、del.icio.usのAPIなど、RESTの制約を満たしていないが、よく知られているサービスを取り上げ、それらをRESTfulに再設計する方法も紹介する。RESTの概念から実装まで、深い知識が得られる本書はWeb開発者必携の一冊である。 はじめに 1章 プログラマブルWebとWebサービス 1.1 プログラマブルWebの概要 1.2 HTTP:エンベロープに入ったドキュメント 1.3 メソッド情
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した. “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて,ビジネスロジックに集中すること目的としている.Heroku特有なものではなく,一般にも十分適用できる知見となっている. 最近は,モバイル向けにAPIをつくることも多いため,勉強もかねて抄訳した.なお内容は,HTTP+JSONのAPIについて基本的な知識があることが前提となっている. 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと.例えば,“成功"を示すステータスコードは以下に従う. 200: GETやDELETE,PATCHリクエストが成功し,同時に処理が完了した場合 201: POSTリクエストが成功し,同時に処理が完了した場合 202: POSTやDELETE,PATCHリク
4/12(土)の夜に『RESTful Meetup vol.3』を開催しました。 RESTful Meetup vol.3 - Sendagaya.rb | Doorkeeper 昨年の記事の通り『RESTful Web APIs』の読書会を月2回ペースで開催してきましたが、その後、著者のMike Amundsen(@mamund)さんから、ワークショップのために東京へ行くという知らせがあったので、これはイベントをやるしかない!ということで企画しました。 vol.3ということで、実は過去2回開催しています。そのときは『RailsにおけるRESTfulなURL設計勉強会』というタイトルで、かなりターゲットを絞っていたのですが、今回は「REST」「Web API」というかなり広いテーマにしました。このことでRuby/Railsに限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか?」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
はじめに Ruby on Rails や同種のフレームワークを使っていると、《REST思想》と《リソース指向》と《Webページ》がごちゃまぜになったWebアプリケーションをつい設計してしまいます。 三つの違いを意識し、適切なWebアプリケーションを作成するようにしましょう。でないと後悔することになります。 なお、この三つの用語は本来の意味とずれているかもしれません。 「コメント」、「編集リクエスト」大歓迎です。 解説 http://yourhost/books のURLで本の一覧が取得できるようなWebサービスを提供するとします。 では /books を含めた各URLはどのように振る舞うべきなのでしょうか。 (URLと言っている部分でも実際はpathを指している場合があります。ご了承ください)
SOAP、WSDL、UDDIなどを基盤とするWebサービスの標準化を行ってきた団体WS-I(Web Services Interoperability Organization)が、2002年からの約8年間の活動に幕を下ろしたことを正式に発表しました(参考:WS-I Completes Web Services Interoperability Standards Work(pdf))。 WS-Iは、WS-*と総称されるWebサービスのさまざまなプロトコル策定に取り組んできましたが、複雑すぎるといった評判がつきまとい、また策定そのものにも予想以上の時間がかかったことなどで、当初の想定ほど普及に至りませんでした。 そのSOAPに代わり、ここ数年サービス間をつなぐAPIとして存在感が高まっているのがREST(Representational State Transfer)と呼ばれるアーキテクチ
移転しました http://please-sleep.cou929.nu/20130121.html
1. RESTful Web アプリの 設計レビューの話 和田 卓人 (a.k.a id:t-wada or @t_wada) July 23, 2012 @ sendagaya.rb 3. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ・クエスト株式会社 取締役社長 4. 私と REST (input) • WEB+DB PRESS vol.32「REST アーキテクチャスタイル入門」 • はてぶ設計議論 • DHH の RubyKaigi 2006 Keynote • WEB+DB PRESS vol.38∼「REST レシピ」 • 『RESTful Web Service』
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く