どんなに当たり前になった開発手法やプログラム管理方法があっても、新人さんにとってはHello worldから入って行くと思う。インターネットで、「知の高速道路」が整備されたと言っても、意外と古い話を探すのは難しい話で、MVCみたいに当たり前になってしまったことについて、何故そんなものが存在するのか？という考え方を後から肌で感じるのは難しく、そんなことを考えていたら、突然MVCについて書きたくなった。 以下、書いていくがかなりの偏見が入っている気はするので、ぜひ、歴史認識が間違ってたら僕のためにツッコんでくださいませ。 僕がMVCアーキテクチャを知ったのは、JavaのServletを勉強していた時だった。Javaはオブジェクト思考で作られている言語かつ、Webに特化した言語ではないため、クラス間のデータは、インターフェース仕様に基いて秘匿されるのと、テンプレートエンジンは別に存在していたので
RESTに関するd4-1977のブックマーク (23)
-
d4-1977 2013/05/25
-
RailsにおけるRESTfulなURL設計勉強会 vol.2 メモ #sendagayarb - 130単位
zusaar.com - zusaar リソースおよび情報 vol.1に続いて参加してきました。そのメモです。 複数レコードを選択して更新するUI 207 Multi-Status を使わないようにがんばりたい 207のレスポンスの中身は設計者任せとされている 項目(トラフィック)が少なければ個別のアクセスもあり Ajaxで複数回リクエストするのはリソース設計の統一感がある 処理を集約したトランザクションリソースを新たにつくる ステータスコード 参考：no title 一部成功時、200を返すのもOK 1の位が0のステータスコードは曖昧さも許容している リソース更新失敗は422 Unprocessable Entity がRailsデフォルト デフォルトに従うのは楽だしその判断もあり しかし表現できるなら表現したほうがいい Uniquenessのバリデーション失敗時は 409 Co
-
RailsにおけるRESTfulなURL設計勉強会 メモ #sendagayarb - 130単位
zusaar.com - zusaar リソースおよび情報 参加してきました。 以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる リソースモデリングパターンの提案 (@tkawa)
-
小さなマイクロブログ『mio』を作っています - とある技術の備忘録
Ruby これは何？小規模のグループで緩くコミュニケーションを取るための、Twitterクローンなマイクロブログです。Rails製です。このGW中に作りました。予め決められたグループで運用することを想定しているため、twitterに比べるとFollow機能等がありません*1が、その分グループ運用に適した他の機能も加わっています。 Timeline Wiki - Show Wiki - Edit なぜ作った？大学の研究室で日々の成果や意見等をつぶやくことで、学生や教員間で進捗を管理しつつコミュニケーションを取り、良い研究室生活を送ろう、という目的のもとで作りました。研究室でなくとも、友人間のグループや小規模なプロジェクト等、色々な用途に使えるのではないかと思っています。 また、Rails3を使ってまともなWebアプリを作ってみたかったので、その学習も兼ねています。コードはこちら(github
-
RailsでのURL設計を考えてみる(5) Railsのリソースパターン - ぶろぐ。@はてな
URL設計の前段階として、とても大切なのがリソース設計です。そのWebアプリ・Webサービスで何を提供するのかが決まる部分だからです。しかし、なかなかリソースという概念が定着していないようなので、Railsで採用されているパターン*1を例に挙げて紹介してみたいと思います。 今までのシリーズ記事と重なるところもありますが、まとめということで…。 リソースとは 簡単に言うと、「URLで示されるもの」です。URLというのが“Uniform Resource Locator”の略ですからね。 http://d.hatena.ne.jp/tkawa/20110819/p1 http://d.hatena.ne.jp/tkawa/20110819 最初のものは、前回書いたブログ記事『RailsでのURL設計を考えてみる(4) スラッシュと「持っている」関係』というリソースです。 その次は、『tkawa
-
Rails3 失敗から学ぶDevise利用時のURL設計 - 130単位
no title 要件 ユーザー登録のあるアプリ メアドで仮登録→本登録で各情報入力 仮登録状態の時は本登録に強制遷移 新規登録とは別にマイページが存在 ユーザーのプロフィール入力とアプリ設定入力は別画面 新規登録では確認画面や完了画面もほしい マイページでの編集時はなしにした やや複雑な仕様のため一般化するのは難しいかもしれませんが、自分が選択したやり方を紹介してみます。 環境 Rails3.0.7 Devise1.3.4 モデル設計 User UserProfile UserSetting UserはDevise用フィールドのみにして、プロフィール等は関連モデルで定義 当初のURL設計(失敗例) #新規登録 match 'register/profile' match 'register/setting' post 'register/confirm' post 'register/c
-
RailsでのURL設計を考えてみる(3) 確認画面のURLは必要か - ぶろぐ。@はてな
今度は「Rails3 失敗から学ぶDevise利用時のURL設計 - 130単位」のコメントをきっかけに考えてみました。 routes.rbの書き換え 新規登録のときに確認画面や完了画面がほしいという場合はよくあります。 もともと match 'user_entry/profile' match 'user_entry/setting' post 'user_entry/confirm' post 'user_entry/create' get 'user_entry/complete' だったものを、 resource :user, :only => :show do resource :profile, :except => [:show, :destroy] resource :setting, :except => [:show, :destroy] end とするのはどうか、と考
-
RailsでのURL設計を考えてみる(2) follow - ぶろぐ。@はてな
前回の「RailsでのfavoriteのURL設計」が思いがけなくそこそこ見てもらったようなので、いろんなパターンのURL設計を考えてみるシリーズをやってみたいと思います。（続くかどうかは未定） こんどはMioからは離れて、といってもほとんど同じようなものですが、Twitterのfollowのような機能を考えてみます。 Twitterの設計 考える前に、TwitterのWebサイトとAPIではフォロー関係の設計がどうなっているか参考に見てみましょう。*1 Webサイト URL フォローしている ユーザ（ツイート） /:screen_name/following フォローしている ユーザ /:screen_name/following/people フォローされている ユーザ /:screen_name/followers API*2 URL 追加パラメータ フォローしている ユーザ（ID）
-
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 ルーティングは
-
第5回デザイナー向けプログラム部 #p4d に参加しました - ぶろぐ。@はてな
昨年の10月ぐらいから参加している「デザイナー向けプログラム部」の第5回が開催されたので、エンジニア枠で行ってきました。 基本的には「気軽に教えてくれるメンター（先生役）のいるハッカソン」ということで、実際に手を動かしてやってみようというイベントなのですが、今回は時間を30分もらってRESTについて話をさせてもらいました。 RESTとRailsスタイル View more presentations from Toru Kawamura 「しっかり準備します」って言ったわりにはあまりちゃんと準備できなくて、スライドの完成度がいまいち、内容もまだ途中（ステータスコードの話が全くない）、という感じなのですが、質疑応答もあってちょうど30分ぐらいになりました。 対象がデザイナーということで、できるだけ専門用語を使わずに、重要なものだけ、とか思っていたのですがスライド見るとそんな感じはないですね…
-
restful_authenticationを触ってみた - idesaku blog
久々にRailsを触っていたら、認証プラグインの定番acts_as_authenticatedが、より新しいrestful_authenticationに変わっていることに気づいた。前者は今後保守されないらしいので、乗り換えは必須。新米RESTafarianとしては、RESTfulを名乗っているところにも興味を引かれる。 そういうわけで触ってみて導入手順を書いたが、RailsのREST実装についての説明も含むので、ちょっと冗長になってしまった。 2010/05/24追記。こちらも参照のこと。 最新版のrestful-authenticationはどこにある？ - idesaku blog インストール まずはrailsアプリケーション作成。今回は2.0.2を使う。 $ rails authtrial create create app/controllers create app/help
-
CakePHPでRESTful
CakePHPは、PHP言語の高速開発用フレームワークです。日々、発展を遂げる各種フレームワークの動向を見極めつつ、日本発のCakePHP応援ブログとして、最新情報をお届けします。 CakePHP 1.1でのRESTfulは下記に記事がありました。 RESTful Web Services With CakePHP http://bakery.cakephp.org/articles/view/150 今回、1.2のRouterでRESTを扱う方法が、php|architect's C7Yに投稿されています。 REST and Resource Handling with CakePHP by Nate Abele (2008-05-14) http://c7y.phparch.com/c/entry/1/art,cakephp-rest ちなみに、現在のCakePHPリードデベロッパーに
-
blog.katsuma.tv
正月休みに実家に戻っていたときに「RESTful Webサービス」を読んでいました。かなり遅くなりましたが、ざっと感想を書いておこうと思います。 序盤はやや難しい 正直、かなり理解するのに苦労しました。REST自体の仕組みは理解していたものの、日本語訳に「？」という点が多々あり、「結局何を言ってるんだ？？」と思ってしまった点が結構ありました。１文、１文は分かるのですが、全体的には理解しにくいと言うか。とは言え、第一章は導入部分で「RESTってそもそも何？」だったり、「RPCなど他の技術との違い」などが中心に話が進んで行く部分なので、別の書籍や雑誌で軽く知識を入れておくと、そこまで苦労はしないかと思います。 WEB+DB PRESS ならここ最近RESTの連載もあるので、その辺り目を通しておくといいかなと思いました。 中盤からが重要 と、いうわけで最初は読むの難しいかなぁと思っていたのですが
-
-
2008-01-02
せっかくなのでURI関係全見直しをかけると同時に、冗長なコントローラーコードはモデルに持って行く活動。コントローラーのコードをモデルに移すことでテストがしやすくなる、というのもあり。 とりあえず、/pages/{action}/{id} ではなく、/pages/{id} でアクセスできるようにしようかと思って、map.resources の使い方をみていたら、脇道にそれて、AtomFeedを作ろう、という話になって、index.atom.builderを書いたものの、「登録されているページの中で自分が閲覧することのできるページを更新順に」というクエリの実行方法に悩む。 自分が閲覧することができる、の条件が、 ページの所有者がアクセス制御をかけていない場合で、匿名ユーザーも含めて公開 ページの所有者がアクセス制御をかけていた場合に - ページの所有者と友人関係にある - すべての友人関係にの
-
yohei-y:weblog: RESTful Web サービスの読みどころ: 3章 RESTfulサービスの特徴
RWSが本屋さんに並びはじめました。 今日外出のついでに神保町に行ってみたら、 三省堂は10冊、書泉グランデは16冊も平積みにされていて 結構圧巻でした。 今日は3章です。 3章では、きちんと RESTful で広く運用されている 数少いサービスの一つである Amazon S3 の ruby クライアントを作りながら、 RESTful な Web サービスの設計とはどんなことなのか、 そのサービスのクライアントはどう作るのか、を解説します。 僕は S3 について、これまであまり知らなかったのですが、 この章を読んでよく設計されているなー感心しました。 もちろん S3 には接続性という、本書で提唱されている ROA に 則っていない部分があるのですが、 それを差し引いても設計の参考になると思います。 特に S3 の認証と認可の仕組みは サービスそのものに課金を考えた場合にとても参考になるでし
-
丸レクでREST on Railsについて話をしてきました
本日、「 丸山先生レクチャーシリーズ RESTfulサービス技術の台頭」で話をしてきた。僕の題目はというと、「Ruby on Rails2.0におけるREST対応」。使用したスライドは下のものである。 | View | Upload your own PDFは こちら 個人的には、やっぱり練習をしていくべきだったかなぁ、と、話し方に関して反省である。何度もRESTとRailsを言い間違えたし、日本語として正しくないよなぁ、と思ってしまうほど文法上酷い言い方をしてしまった部分もあった。しかも、かなりの早口になっていたはずで、45枚あるスライドで、しかも途中でデモもやっているのに、時間が余るって何だよ、ってことになってしまった。まだまだスキルが僕は足りないな、と痛感。 しかし、会場に来ていただいた方々からのアンケート結果は、意外にも高評価。「わかりやすかった」「RailsでのREST対応があん
-
-
scaffold_resource？ - TYAGE EMOTION
ようやく休日の仕事から解放されたので、久々にやりたいことをやってます。 連休の前半はJavaのプログラミング、作ってた内容はそのうち書けると思います。 そして今日はようやくRailsの勉強をはじめました。 昨年買ったまま放置していた「RailsによるアジャイルWebアプリケーション開発」を今頃読んでます。当時はRubyの文法もろくに覚えてなかったのですが、今は少々わかるようになりました。 しかし面白いですねこの本。以前、Railsがテーブルからscaffoldすることに対する批判を読んだことがあって、当時は「なるほど」と思ってそのまま思考停止していたのですが（汗）、この本を読むと、あくまでイテレート開発のとっかかりとしてテーブルスキーマを利用してるんだということがわかって、なんとなく納得しました。とにかく動くものを最速で作りながら、その成果物を検証材料にして繰り返し開発を進めていくって考え
-
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2024 Hatena. All Rights Reserved.
設定を変更しました