Favoriteのパターン化
はじめに Ruby on Rails Advent Calendar 2013 5日目 「Favoriteの設計実装はパターンとして使える」 http://qiita.com/tkawa/items/ac01dbc1e441e78ffcfd 一見設計しにくい「操作」はパターンに落とし込めるのでは、という話です。 class TodoList < ActiveRecord::Base has_many :todo_items, -> { order(position: :desc) } def sort! # self.todo_items の position を書き換えてsaveするコード end end class TodoItem < ActiveRecord::Base # name: string # position: integer belongs_to :todo_lis
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
Rails で、Controller に定義されている action を一度に取得する方法はありますか？ - QA@IT
平素よりQA＠ITをご利用いただき、誠にありがとうございます。 QA＠ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA＠ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、＠ITの今後のメディア運営方針などを検討した結果、2020年2月28日（金）15:00をもちましてQA＠ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA＠ITの7年間で皆さまの知識
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を混同している とりわけ後者は僕を困らせたが、あるチームをコーチすると
ハイパーリンクは何を繋ぐのか - 檜山正幸のキマイラ飼育記 (はてなBlog)
[追記] この記事内で、既存の用語の意味をズラシたり拡大解釈して記述したところがあります。「既存の解釈に強く拘らない」というのがひとつの（僕が推奨する）方策ですが、「もう少し、ハイパーメディア・アプリケーションについて」も一緒に読んでくださるのがヨイかと。 [/追記] 『RESTful Webサービス』という本はよく参照しましたし、このブログ内でも何度か言及・引用しています。 RESTful Webサービス 作者:Leonard Richardson,Sam Rubyオライリー・ジャパンAmazon この本はたいへん勉強になりました。しかし、多少の違和感が残る、なんか不足を感じる点もあります。この本の著者達、リチャードソン＆ルビーと僕のあいだで、どこかに認識やメンタルモデルの食い違いがあるみたいです。それは（仮にあったとしても）微妙な点なので、なかなか明文化はしにくいものです。 最近また『
RailsのURL設計を考えてみる(6) 設計の選択肢 - ぶろぐ。@はてな
今回は直接Railsとは関係ないのですが、先日こういうページを見つけました。 http://redrata.com/restful-uri-design/ これは2009年に書かれたもののようですが、URL設計に関する重要な考え方がいろいろ書かれています。 その中に、このブログのシリーズの(4) スラッシュと「持っている」関係や(5) Railsのリソースパターンの前段階になるような“Choosing a URI schemes for resource hierarchies”という話があったので、かいつまんで紹介したいと思います。 リソースの階層に対して、どういうURLを設計するか？ 前提として、設計するWebサイトには、conversation（会話）というリソースが複数あり、それぞれのリソースはユニークなIDで区別されるとします。（IDは数字とは限らない識別子） /conversa
RESTfulアプリケーションのパフォーマンス - winplusの日記
『RESTful Web Services Cookbook』の著者であるSubbu Allamarajuの記事Subbu’s Blogを適当訳しておく。図やリストは元の記事を参照して欲しい。 ちょとまえにiPhone上で動いているいくつかの有名なアプリケーションがいかに「おしゃべり」かってことを示した。でもこの記事は、電話とかそれに似たやつで動く目新しいユニークなアプリケーションについてのものじゃない。分散化された/非中心化されたサーバーからいかに効率的にデーターを手に入れるかというのは、分散コンピューティングではよく知られた問題だ。たとえば、1994年11月の論文「分散コンピューティングについての覚書」の概要で、Jim Waldoは次のように記している（強調は筆者）。 分散環境中で相互作用を行うオブジェクトは、単一のアドレス空間中で相互作用を行うオブジェクトとは本質的に異なった方法で取
こんなURI設計、どう？ - 岩本隆史の日記帳（アーカイブ）
先日書いたように、作りたいWebサービスがあります。当然ながら、まずは設計から始めなければなりません。 設計にあたっては『Webを支える技術』の第15章で紹介されているサービス設計手法を用いることに決めたのですが、URI設計のステップで、はたと考え込んでしまいました。 以下、第15章に掲載されているURI例で違和感の原因を探ってみます。 郵便番号リソースのURI http://zip.ricollab.jp/1120002これは違和感ありません。 検索結果リソースのURI http://zip.ricollab.jp/search?q=小石川ここで若干の違和感を覚えます。郵便番号データのキーである「1120002」と「search」が同列に並んでいるのが原因です。 いや、とくに気にする必要はないのかもしれません。「search」という郵便番号は今後も現れないでしょう。もし現れたとしても、ク
RESTとバージョニング
原文(投稿日：2010/06/13)へのリンク 最近Ganesh Prasad氏はRESTアーキテクチャにおけるサービスのバージョニングという非常に悩ましいテーマについて検討している。例えば "/customers/1234"で表わされるリソースがあるとします。この顧客情報の状態を更新するためにPUTが必要です。しかし、PUTに対応するビジネスロジックの更新を、RESTはどうやって取り扱えるのでしょうか？ サービス（ビジネスロジック）を指定するために使用されるオペレーションを変更する（例：PUTv2を指定する）方法は存在しない。選択肢の１つはPUT対象のURLを変更し、同時に元のURLもメンテナンスすることだ。Ganesh氏は以下のような例を示している。 /customers/1234というURLは残し、PUTはそれとは別のURL /customers/v2/1234 に対して行います。
たかが URI の設計、されど URI の設計 | システム設計日記
関心事オブジェクトの「現在の状態」を利用者に提供するパターンのひとつが、REST スタイルの GET 方式。 GET /リソースの識別名(URI) をサーバーにリクエストすると、「現在の状態 ( current state )」の表現 ( Representation ) がかえってくる、というやつですね。 ドメインモデリングのパターンとして、私は、「リソース」を「関心事オブジェクト」、「ＵＲＩ」を「識別キー」という言葉にしている。 実際に、HTTP を使うかどうかは別として、 ◎ リソース（＝関心事オブジェクト）の ◎ URI (＝識別キー) を指定して ◎ 現在の状態(current state)を入手する というのは、エンタープライズアプリケーションの基本価値のひとつですね。 「関心のあることを知る」という業務の基本ニーズ。 このニーズに応えるための GET 方式のモデリング・設計は
Towards RESTful PHP - 5 Basic Tips · Kris Jordan
What is REST? REST is an architectural style, or set of conventions, for web applications and services that centers itself around resource manipulation and the HTTP spec. Web apps have traditionally ignored the HTTP spec and moved forward using a subset of the protocol: GET and POST, 200 OKs and 404 NOT FOUNDs. As we entered a programmable web of applications with APIs the decision to ignore HTTP
REST vs SOAP
GET /WebSite1/WebService.asmx/getHello?str=string HTTP/1.1 Host: localhost HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <string xmlns="http://tempuri.org/">string</string> RESTは、WebブラウザのAjaxや、クライアントアプリから使う場合もあるが、サーバ間のシステム連携でも使う。 RESTの最大の特徴は「WebブラウザにURLを入力すれば動作確認できる」事である。 Webブラウザで容易に動作確認ができるため、すでに存在しているサービスに対しては「まずはアクセスしてみて必要な情報
Rails2.0の足回りと中級者への道：第2回 Rails2.0で作るRESTfulアプリケーション（前編）｜gihyo.jp … 技術評論社
前回の記事では、Rails2.0の足回りを簡単に概観しました。今回は、実際にRails2.0の機能を利用し、RESTfulなウェブアプリケーションを作ってみたいと思います。 RESTとは何か Rails2.0の機能を用いて、RESTfulなアプリケーションを作るまえに― RESTとは、いったいなんでしょうか？ という問いに対して、正確に答えるには私の知識はこころもとないです。Wikipedia日本語版のRESTの項を引いてみると、「表現可能な状態を転送するもの」と書かれてありますが、これだけ翻訳してもよくわかりませんね。用語としての初出は、2000年に、HTTPプロトコル規格の主要著者の一人であるRoy Fieldingがウェブについて書いた博士論文「Architectural Styles and the Design of Network-based Software Archite
ricollab Web Tech Blog » Blog Archive » RESTアーキテクチャスタイル入門の記事をすべて公開しました
1月に三分の一を公開して以来、ずるずると遅れていた残りの記事の公開をやっと行いました。 RESTアーキテクチャスタイル入門 Web アプリケーションのアーキテクチャ Web サービスと REST RESTful な URI の設計 出版は2006年なので2年前の記事です。内容が一部古くなっている部分もあったため、現時点での最新情報に少しだけアップデートしました。
ricollab Web Tech Blog » Blog Archive » RESTとリソース指向アーキテクチャについての資料
2/12 に NTT コミュニケーションズ様の社内勉強会にて、REST に関する講演をさせていただきました。NTTコミュニケーションズ様の了解をいただいたので、その資料を公開します。 REST を具現化するアーキテクチャとして、「RESTful Web サービス」で提案されているリソース指向アーキテクチャ(Resource Oriented Architecture; ROA) をご紹介しました。 TrackBack URI “RESTとリソース指向アーキテクチャについての資料” に対するコメント(1) Slashcolon /: さん: 2008-02-15 0:07:11 RESTとROAの基本をお勉強… まぁ、REST の基本は押さえておきたいと言うか、押さえておかないとWeb 2.0が語れないらしい NTT コミュニケーションズの社内勉強会での講演資料… 『RESTとリソー
REST入門
第2版（2008年1月19日）：翻訳者による注釈を追加しました。 ヘテロジニアスなアプリケーション間の通信を実装するための「適切な」手法について議論が行われているということを、あなたは知っているかもしれないし、知らないかもしれません。そういった状況下で、現在の主流は明らかにSOAP、WSDL、WS-*仕様という世界をベースとしたWebサービスにフォーカスしています。しかし、少数派の人たちの中で、より良い方法があると主張する人がいます。それが、REST(REpresentational State Transferの略)です。本稿では、本筋から外れることなく、RESTとRESTfulなHTTPアプリケーション統合への実用的な説明を試みようと思います。これらの考え方の説明については、より詳細に踏み込んで説明をするつもりです。私の経験上、誰かが始めてこのアプローチを経験することで一番議論が活発に
A Brief Introduction to REST
Here are some examples of URIs you might come up with: http://example.com/customers/1234 http://example.com/orders/2007/10/776654 http://example.com/products/4554 http://example.com/processes/salary-increase-234 As I’ve chosen to create human-readable URIs — a useful concept, even though it’s not a pre-requisite for a RESTful design — it should be quite easy to guess their meaning: They obviously
ステートレスとは何か
RestWiki をたまに見直すと新たな発見があって面白い。 たとえば先日、「ステートレスなやりとりとは何か(What is Stateless Interaction?)」という箇所を見つけて、興味深く読んだ。このページは以前も絶対に読んでいるはずなのだが、 人間は忘れてしまうものである。 RestWiki の例でも充分わかりやすいのだけれど、自分でも例を思いついたので書きとめておく。 ステートフルサーバとステートレスサーバはどう違うのか。 まずは、ステートフルの例: 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員:
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
RESTのインピーダンスミスマッチ
REST APIの良い、悪い、醜い
