Railsの誤解：CRUDはRESTじゃない！ - 杉風呂2.0 - A Lifelog -
以下はNick Sutterer氏が2010年10月28日に自身のブログに投稿した、"Rails Misapprehensions: CRUD is not REST! "の翻訳です。本人の許可を得て掲載します。 Rails Misapprehensions: CRUD is not REST! http://nicksda.apotomo.de/2010/10/rails-misapprehensions-crud-is-not-rest/ RailsとRESTについて調べている間、二つのことがよくわかった。 RailsでRESTがどうなっているのか、他と比べて、明解で、基礎的で、「印刷された」解説を見つけにくい。数千のスクリーンキャストを見てきたが、この素晴らしいガイドが一つあるだけだった。 みんなCRUDとRESTを混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると
WebサービスAPIにおけるバージョン情報の指定方法 - Sooey
Herokuアドオンとしても提供されているFlying SphinxのAPIを開発したデベロッパーの方が、APIのバージョニングについて面白いエントリを書いていました。 Versioning your APIs : Freelancing Gods APIのバージョンを明示してアクセスする場合は、 https://api.twitter.com/1/statuses/user_timeline.json というようにURLにAPIバージョン（この場合は1）が含まれるようなスタイルが多いですが、ScalariumというサービスのAPIでは、HTTPヘッダに Accept: application/vnd.scalarium-v1+json というようにしてAPIバージョンを含める仕様となっています。 後者についてはAsk HN: Version numbers in a REST APIで、
Rolling with Ruby on Rails
Now, next, and beyond: Tracking need-to-know trends at the intersection of business and technology AI/ML Few technologies have the potential to change the nature of work and how we live as artificial intelligence (AI) and machine learning (ML). Future of the Firm Everything from new organizational structures and payment schemes to new expectations, skills, and tools will shape the future of the fi
RailsでのfavoriteのURL設計 - ぶろぐ。@はてな
http://d.hatena.ne.jp/r7kamura/20110505/1304577667がすごいなと思って、routes.rbの書き方の例についてコメントしたのですが、自分で書いておいて後で「unfavorite」はちょっとまずいかなと思ったので、favorite（いわゆるお気に入り、スター）はどういうふうに設計すればいいのか考えてみました。 構造はよくある感じの、 tweet has_many favorites user has_many favorites 任意のツイートに任意のユーザーがお気に入りをつけられるというもの。別にツイートじゃなくても何でもOKです。 ブログのコメントにはこのように書きました。 (1) resources :tweets do member do post 'favorite' post 'unfavorite' end end ルーティングは
yohei-y:weblog: REST ってやっぱり難しいかも。
前のエントリでこんなことを書いたばかりだけれど、REST ってやっぱりどうよ、という気分になったので久々に blog を更新してみる。 ただただしさんのおれだったらフォト蔵APIをこうするを読んで、僕が del.icio.us に書いた感想は +1。ID == URI ですよね。Cool URI は名詞であるべき、というのは強調したい。「日本REST協会」入りたくないなー(笑)。みんな休んでそう というもの。たださんのエントリでは URI と書くべきところが ID になっててちょっと気になったり、「作法」は「アーキテクチャ」じゃなくて「アーキテクチャスタイル」だ、とか思ったのだけれど、でも本筋としては納得の内容だった。 しかし、たださんのエントリの、たかはしさんや mizzy さんのコメントを読んでうーんと唸ってしまった。 僕にはお二人の言いたいことがわかる。んで両方間違っていないと思う。
最近のRESTの進化。バージョン番号、状況報告、プロダクトとしてのAPI
RESTの時代がやってくるのだ、という記事を1つ前の「時代はRESTへ。SOAPの終わりを象徴する、Webサービス標準化団体のWS-Iが活動終了」で紹介しましたが、そのRESTも使われ方が進化してきているのだ、ということを、その記事の中でとりあげたProgrammableWebのJohn Musser氏が公開しているの資料の中で解説しています。 3つ紹介しましょう。 バージョン番号の組み込み 最近のREST APIにはバージョン番号がURIに埋め込まれるようになったとのこと。 利用者に状況報告 レイテンシーがどうなっていて、正常稼働しているかどうかといった報告を利用者に対してきめこまかく報告するようになったと。APIに依存した外部サービスが増えたためでしょうね。
RESTをどんなふうに説明するか - winplusの日記
http://tech.groups.yahoo.com/group/rest-discuss/messages/16621?threaded=1&m=e&var=1&tidx=1から適当に。 Sean Kennedy 私はアカデミーで働いていて、RESTfulな設計の利点について学生に伝えるために努力しています。私が最初にRESTに出会ったとき、それは以下の制約に従うスタイルとして説明されていました[1]。 すべてのものにIDをつける おたがいにものをリンクする 標準化されたメソッドをつかう 多重の表現 ステートレスなやりとり 私はこの夏、Royの論文を読みました。私なりに要約すると、次のようになります。 「RESTとは、他のネットワークベースのアーキテクチャスタイルから派生したハイブリッドスタイルです。アーキテクチャスタイルを使うことは、システムに関連する制約を適用することです。それぞ
Railsを使ったRESTfulなAPIの作り方 - プログラミングノート
サーバーと連携するiPhoneアプリをそろそろ個人でも作ろうかなと思ったので、とりあえず開発したことのある方法をまとめてみました。今回はrails 2.3.8, ruby 1.8.7, nokogiri 1.4.3.1な環境で作っています。 簡単な仕様 タスクをCRUDできるだけの単純なAPIを作ります。 下記のメソッドを用意して、XMLとJSONのフォーマットに対応します。 method URI params その他 検索 GET /api/search.format kw=検索ワード kwがない場合は全件返す 表示 GET /api/tasks/id.format 登録 POST /api/tasks/id.format name=タスク 編集 PUT /api/tasks/id.format name=タスク 削除 DELETE /api/tasks/id レスポンスヘッダのみ返す
たかが URI の設計、されど URI の設計 | システム設計日記
関心事オブジェクトの「現在の状態」を利用者に提供するパターンのひとつが、REST スタイルの GET 方式。 GET /リソースの識別名(URI) をサーバーにリクエストすると、「現在の状態 ( current state )」の表現 ( Representation ) がかえってくる、というやつですね。 ドメインモデリングのパターンとして、私は、「リソース」を「関心事オブジェクト」、「ＵＲＩ」を「識別キー」という言葉にしている。 実際に、HTTP を使うかどうかは別として、 ◎ リソース（＝関心事オブジェクト）の ◎ URI (＝識別キー) を指定して ◎ 現在の状態(current state)を入手する というのは、エンタープライズアプリケーションの基本価値のひとつですね。 「関心のあることを知る」という業務の基本ニーズ。 このニーズに応えるための GET 方式のモデリング・設計は
RESTfulサービスを設計する - winplusの日記
※オライリーから翻訳書『JavaによるRESTfulシステム構築』が出ましたので、そちらを参照してください。以下の記事はアテになりません。 以下『RESTful Java with JAX-RS』「Capter2:Designing RESTful Services」のメモ。目次はこちら この章では、簡単な注文入力サービスのRESTfulなインターフェイスを定義する。 オブジェクト・モデルからはじめて、まずURIを決め（アドレス可能性を満たす）、次にデータフォーマットを決め（表現指向）、最後にそれぞれのURIでどのHTTPメソッドを許可するかを決める（統一インターフェイス）。 ■オブジェクト・モデル 注文は特定の顧客に関連づけられ、いくつかの項目で構成される。項目は購入された商品の型と数量を表す。 モデルは、Order, Customer, LineItem, Product。どのモデルも
routes-master
Routes職人への道 (株)万葉 大場寧子 2010/02/28 @ TokyoRubyKaigi 03 このワークショップの目的 • Railsでは、URLとアクションを結びつける設定を config/routes.rb に記述します。 • Rails3では、以前のデフォルトであったマッピング /:controller/:action/:id が外されます。 • Railsできちんとしたアプリケーションを作るには、routes.rb をすらすら書けるスキルが大変重要です。 • routes.rb の書き方をよく理解していないと、思い描いたURLを実現できなかったり、メンテナンスしづらくなったりします。 そこで、このワークショップでは、皆さんにroutes.rbとお友達になってもらい、ストレスなく書ける基礎スキルを身につけてもらうこ とを目指します。現場で役立つ「routes職人」への第
yohei-y:weblog: 『Webを支える技術 ── HTTP、URI、HTML、そしてREST』という本を書きました
このブログ、1年近くご無沙汰していました。その間なにをやっていたかというと、実はずっと本を書いていました。『Webを支える技術 ── HTTP、URI、HTML、そしてREST』というなんとも挑戦的な題名の本です。技術評論社さんのWEB+DB PRESS Plusシリーズの11冊目で、来月発売される予定です。 Webを支える技術 ── HTTP、URI、HTML、そしてREST山本 陽平技術評論社 2010-04-08 この本は、WEB+DB PRESSで連載していた「RESTレシピ」という連載がベースになっています。実は連載が1年経ったくらいから、技評さんからは書籍化のオファーをもらっていました。ただ、その時点では書いた分量も少ないし、そもそも自分に雑誌記事とは比べ物にならないくらい分量のある本が書けるとは思っていなかったので、書籍ではなく連載継続という形でトータル2年間連載をしました。
[Ruby][MashUp] WebAPI 用 Rubyモジュール
WebAPIのMashUpをしていると、リクエスト＆レスポンスの処理を統一して扱うフレームワーク的なものが欲しくなります。RubyでWebAPIを扱うための標準的なライブラリがありそうですが、知らないので簡易モジュールを書いてみました。 # みんなどうやっているのだろう... # この程度の処理は、ふつうのプログラマならさくっと自分で書いているのでしょうか。 モジュール名は(使い方が正しいのか微妙ですが)、RESTとしています。 require 'uri' require 'cgi' require 'open-uri' require 'rexml/document' require 'rexml/parsers/streamparser' require 'rexml/parsers/baseparser' require 'rss' module REST class RESTReq
yohei-y:weblog: REST 入門
日本語の REST のリソース集を以前作ったのだが、 日本語では一般人向けの解説がない。 sheepman 氏の REST のページはすばらしいんだけど、多少わかっている人向けだ。 市山氏のプレゼン資料は RoyF の論文を詳しく解説していてよいのだけれど、いかんせんアカデミックすぎる。 技術的な要素も抑えつつ、入門者にもわかりやすい解説はないものかと探していたのだが、みつからない。 英語の文書を訳すことも考えたんだけど、あまりよいものが見つからない。 で、結局自分で書くことにした。 最初はひとつのポストで済ませるつもりだったんだけど、書き始めたら長くなってしまったので、複数のポストに分けることにした。 えらそうなことを書いたが、内容は「ないよりマシ」といったレベルだろう。 前書きが長くなったけど(ここから始まりです。ですます調なのは入門記事だから)、 この記事(から始まる一連のポスト)は
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[REST] 認証が必要な API を REST っぽく作るときのメモ - それはBooks
REST APIの良い、悪い、醜い
