Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 Webアプリケーションにて、リソースの一部更新を行う際、どのようにURL設計を行うとシンプルで美しいか（本当はそこまで考えていなかったけど）悩んでいたところ、 @t_wada さんから素敵な設計指針をご教示いただきました。 本記事はその内容に加えて、実際に自分で行ったこと、調べたこと、思った事など、まとめております。 あらすじ 数週間前にSIピラミッドからヒモなしバンジーを決めてWebの世界に飛び込んだ私は、小さな小さなWebアプリケーションをrails newから手探りで作っていました。 そんなとき、簡単なリソースの一部更新機能
“The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on. In other words, any concept that might be the target of an author's hypertext reference must fit within the definition of a r
読書会に関して グループで声に出して輪読し、疑問点などを出しつつ、川村さんに質問するという形式で行っています これまで6回開催し、3、5、6、7、8、9章を抜粋して読みました。 「#RESTudy」で検索すると、話し合われた内容等がわかると思います。 今回は以下のページからやりますので、当日までに目を通していただくと良いです。 「P132 9.6 コンテントネゴシエーション」 会場について 設備 Wifiあります 飲食できます 但し、ゴミは持ち帰ってください 禁煙です 20時までに来場される場合 ビルの正面玄関(サンクスの左手)からエレベーターに乗り、7階までお越し下さい。 20時以降に来場される場合 正面玄関から見て右側に通用口があります。 そこにあるインターフォンで 702 を鳴らしてください。 開錠されましたら通用口から入り、エレベーターに乗って7階の会場までお越しください。 ※ 2
『るびま』は、Ruby に関する技術記事はもちろんのこと、Rubyist へのインタビューやエッセイ、その他をお届けするウェブ雑誌です。 Rubyist Magazine について 『Rubyist Magazine』、略して『るびま』は、Rubyist の Rubyist による、Rubyist とそうでない人のためのウェブ雑誌です。 最新号 Rubyist Magazine 0064 号 バックナンバー Rubyist Magazine 0064 号 Rubyist Magazine 0063 号 Rubyist Magazine 0062 号 Kaigi on Rails 特集号 RubyKaigi Takeout 2020 特集号 Rubyist Magazine 0061 号 Rubyist Magazine 0060 号 RubyKaigi 2019 直前特集号 Rubyist
RubyKaigiの発表のために考えていたのですが、発表本編に詳しく入れられなくなりそうなので、まとまりないですがブログに書いてみます。 SOAPでいうWSDL(Web Service Definition Language)のような、サービスのインタフェースを定義・記述するためのしくみを総称してIDL(Interface Description Language)と呼びます。 JSON Hyper-Schema*1もIDL、サービスディスクリプションの一種といえます。 WebのIDLは今までにもたくさん出てきて、しかしうまくいっていません。 なぜでしょう？ @yohei さん曰く、 RESTは統一インタフェースなんだから、そこにさらにインタフェースを定義するのはおかしい （API Meetup #1 質疑応答より） WebAPIのこれまでとこれから from yohei これはどういうこ
mozaic.fmでRESTの回が企画されているということを、API Meetup #1 のときに yohei さんから直接聞いていたのですが、ついにそれが公開されたので、喜び勇んで聴きました。 mozaic.fm #7 REST 断片的に感想をツイートしたので、そのまとめです。 RESTの何が重要なのか さすがの t_wada さん。アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる、という話の流れでした。 “Constraints are liberating”「制約は自由をもたらす」は僕が好きな言葉ですが、これを知ったのはDHHのRubyKaigi 2006の講演からです。（初出はどこか別のところなのかも？） RESTの流行 原理主義者的発言をするなら、「REST API」と謳って世に出たWeb APIはただのJSON/X
Presentation I gave at JPoint Meetingpoint (in a slight different version) and GotoCon Amsterdam 2012. How to get your API or service from using the basic REST principles such as verbs and resources to a complete RESTful service that fully supports "Hypermedia as the engine of application state" (HATEOAS). More info at www.smartjava.orgRead less
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
XMLの操作を標準化した物としてDOMやらXPathやら各種規格が存在するわけですが、JSONでもそのようなよく利用される操作を共通化した物が存在すると便利な場面もあるかもしれません。 そこでIETFのappsawg WGで提案されているのが、JSON PointerとJSON Patchです。 まだ提案されたばかりでほとんど何も決まっていないのが実情なのですが、もしRFCとして公開されるほどの物が出来上がれば、標準的な枠組みとしては強力な物になるかもしれません。 JSON Pointer JSON PointerはXMLで言う所のXLinkとXPathの機能を併せ持ったような物で、JSONの構造の中のあるオブジェクトを表すのに用いられたり、URL中においてfragment identifierとして使われる事でJSONの構造中の特定のオブジェクトを指し示すのに使われる事を想定しています。
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』
The document discusses routes.rb in Rails applications. It notes that some developers find routes.rb confusing and messy. The document then analyzes some potential issues with routes.rb, including that the resources method is not very intuitive and that Rails routing is not fully convention over configuration. It also discusses prior work like Conventional Routes and Astaire that aimed to simplify
The document discusses making Rails applications more RESTful. It promotes improving resources in Rails by using the Restfulie plugin. The document advocates for consistency, simplicity and discoverability in RESTful design. However, it notes that just using HTTP verbs and pretty URLs does not necessarily make an application truly RESTful. It outlines the principles of REST including identifying r
Tim Bray’s article on RESTful Casuistry revisits an odd meme in the REST debates that I’ve been meaning to discredit for a while. Some people think that REST suggests not to use POST for updates. Search my dissertation and you won’t find any mention of CRUD or POST. The only mention of PUT is in regard to HTTP’s lack of write-back caching. The main reason for my lack of specificity is because
第1回読書会 まとめ † 以下のものはあくまでもスタッフ目線です。参加している方もがんがん更新してください。（そこは違うんじゃね？というのをお待ちしてます） ↑ 現地到着〜開場〜設営 † 現地到着 田町の芝浦口から本当にすぐ これは便利だ 場所もわかりやすい 開場が15分遅れ 会場手続きをできるメンバーが限られていたため 他の人でもできないかを確認する ものすごくいい会場 設備が整っていて、きれいでものすごくいい会場でした。 こんな会場を使えるなんてのはやはり幸運としかいいようがない。 設営に手間取る スタッフの誰も会場の下見ができていなかったため、どのように使用するかという段取りも含めて行ったため ネットワークの準備に時間がとられる 結局会場のネットワークは使えず・・・ 本当に使用できないかは確認すべき 次回以降はe-mobile等を使うことも検討 UStreamで参加するつもりだった方
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く