DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
[ウェブアプリケーション][Ruby on Rails]『RESTful Webサービス』でRailsを覚える | アペフチ
今日はちょっと思い出話でも。 Groongaもくもく会＠札幌 2015-12-30に参加して来た。帰札した翌日から熱を出して寝込んでいたのだが、直前で治って本当によかった。 もくもく会ではDroonga HTTP Serverのインストールスクリプトの修正を試みていた。進捗はこんな感じ：https://github.com/droonga/droonga-http-server/compare/master…KitaitiMakoto:centos-systemd その後は忘年会＠Sinatra札幌＆Sapporoonga 2015-12-30。そこで話題になった一つに、Railsの躓きポイントの話があった。既にうろ覚えだがこんな感じだったと思う。 ウェブアプリケーションを作ったことがない状態でRailsに入門すると、どこで何が起こっているか分からない。scaffoldしてアプリケーション
![[ウェブアプリケーション][Ruby on Rails]『RESTful Webサービス』でRailsを覚える | アペフチ](https://cdn-ak-scissors.b.st-hatena.com/image/square/640a03f5121bf4016a87946345e753bf9f90f7b4/height=288;version=1;width=512/https%3A%2F%2Fdiary.kitaitimakoto.net%2Fimages%2Ficon.png)
Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)
といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山本 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいい本だと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という２つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく
[iOS] 用途別、iOSアプリ開発に役立つオススメのWebサービス10選+α | DevelopersIO
はじめに iOSアプリの開発時に使用しているツールやWebサービスを用途別にまとめてみました。 目次 WebAPIの動作を確認したい JSONのフォーマットを検証したい とりあえず、アプリにダミー画像をいれたい それっぽい写真やアイコン素材を入れたい RGB値から16進数のカラーコードからへ変換したい iOS 7以降のシンプルなデザインに合いそうなカラーコードを取得したい 特定の住所の緯度経度を取得したい iOSプロジェクト向けの.gitignoreファイルを入手したい WebAPIの動作を確認したい DHC - REST/HTTP API Client APIにリクエストを投げて結果を確認することができるChrome拡張です。開発中のAPIの動作検証に使用することができます。リクエストヘッダやボディなどの設定を保存することができるので開発中の確認に便利です。 その他のツール Postma
![[iOS] 用途別、iOSアプリ開発に役立つオススメのWebサービス10選+α | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/3b908864d8ed9e4027eb1c344eb948e4eb8ce49a/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F11%2Fios8.png)
RESTのベストプラクティス | POSTD
現在ではREST APIはとても一般的な話題です。ほとんどすべてのWebアプリケーションの一部分となっています。シンプルで一貫性があり実際的なインターフェースは必須です。これは皆さんのAPIを他の人が使うことをとても容易にします。皆さんにとってはRESTの実践が日常的に感じられるかもしれませんが、RESTをあまり尊重しない人々もよく見かけます。これがRESTについて投稿するきっかけでした。 この記事にはRESTfulなAPIを設計する時に考慮すべきベストプラクティスがあります。 注意 : ここでのベストプラクティスは、私が過去の経験に基づいて良いと考える事例です。もし違う考えをお持ちであれば、お気軽にメールをくだされば意見交換できると思います。 APIのバージョンを示す APIのバージョンは必須であるべきです。これがあると時間が経ってAPIが変わっても影響を受けません。その方法の1つはUR
makopi23のブログ 「RESTful#とは勉強会2」に参加しました
2014/11/28(金) 「RESTful#とは勉強会2」に参加してきました。 DoorKeeper http://rubychildren.doorkeeper.jp/events/17514 ちなみに私、ちょうど会社でRESTの必要性に迫られて、以下の書籍で独学している最中なのです。 この本は、JavaのRESTに関する仕様であるJAX-RSの本です。現在、読みながらちょとずつ写経中。 そんな私にとって、この勉強会はタイムリーなネタなのでした。 ちなみに前回も参加したかったんですが、他の勉強会と被ってしまって残念ながら行けなかったのでした。。。 なので今回が初参加。 この日は前半が「Webを支える技術」の読書会で、後半が @t_wada さんの講演でした。 とても参考になる勉強会だったので、当日のツイートをTogetterにも纏めてみました。 http://togetter.com/
REST APIを記述せよ！Swagger紹介 #apijp - Groovyラボ
Web API Advent Calendar 2014、初日はSwaggerを紹介します。 SwaggerはReverbによって開発された、RestfulなAPIを記述する標準仕様です。APIを機械可読な形で記述することは、ドキュメント生成やツール開発、さまざまな形での自動化に非常に重要です。好き嫌いはともかく、SOAPにはWSDLという統一標準がありましたが、RESTには本質的にそういった標準がないため、類似するさまざまな仕様が開発されてきました。Swaggerはその中でも最も有望なものの一つだと思います。 1. 特徴 記述はJSONでシンプル。ミニマム定義の例： { "swagger": "2.0", "info": { "version": "1.0.0", "title": "petstore" }, "paths": { "/users": { "get": { "respon
RESTful Web API 開発をささえる Garage - クックパッド開発者ブログ
技術部の小野(@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
RESTful Meetup vol.3 を開催しました #RWABookja - ぶろぐ。@はてな
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に限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ
《REST思想》と《リソース指向》と《Webページ》を一緒にしてはいけない - Qiita
はじめに Ruby on Rails や同種のフレームワークを使っていると、《REST思想》と《リソース指向》と《Webページ》がごちゃまぜになったWebアプリケーションをつい設計してしまいます。 三つの違いを意識し、適切なWebアプリケーションを作成するようにしましょう。でないと後悔することになります。 なお、この三つの用語は本来の意味とずれているかもしれません。 「コメント」、「編集リクエスト」大歓迎です。 解説 http://yourhost/books のURLで本の一覧が取得できるようなWebサービスを提供するとします。 では /books を含めた各URLはどのように振る舞うべきなのでしょうか。 （URLと言っている部分でも実際はpathを指している場合があります。ご了承ください）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WebAPIのこれまでとこれから
IBM Developer