DHHはどのようにRailsのコントローラを書くのか | POSTD
私たちの救世主DHH™は最近の Full Stack Radioのインタビュー で、 Basecamp の最新版で彼がどのようにRailsのコントローラを書いたかを説明しています。下記は、彼のすばらしい話を書き取ったものです。 これまでに思うようになってきたのは、「RESTの原則に従うには、どのタイミングで新たなコントローラを作るべきかを一度決めたら、ほぼ異例なくその原則を遵守するべきだ」ということです。いつだってその方がうまくいくんです。自分の作ったコントローラの状態を悔やむのは決まって、作ったコントローラの数が少なすぎた時です。多くの処理を任せようとしすぎてしまうんです。 そこでBasecamp 3では、ある程度理にかなったサブリソースがあれば、毎回コントローラを分割していきます。フィルタなどの場合ですね。例えば画面があって、それがある状態になっているとします。もしこれにいくつかのフィ
DHH流のルーティングで得られるメリットと、取り入れる上でのポイント - KitchHike Tech Blog
はじめに こんにちは。KitchHikeエンジニアの小川です。KitchHikeでは主にサーバーサイドを担当しています。 少し前のものですが、「DHHはどのようにRailsのコントローラを書くのか (原文)」というすばらしい記事があります。Railsのコントローラ分割の(DHH流)ベストプラクティスについて解説した記事なのですが、私はこの記事に大変感銘を受け、KitchHikeのルーティング定義にもこのプラクティスを取り入れるようになりました。 本日はこのDHH流ルーティングを取り入れることで得られるメリット、実際の routes.rb でのルーティング定義のしかたについて紹介したいと思います。 DHH流ルーティングとは？何がうれしいの？ 詳しくは元記事を是非とも読んで下さい・・・なのですが、かいつまむと、ここで示されているのはたったひとつの単純明快なルールです。 コントローラはデフォルト
RESTful API の設計のキホン
2016/10/12 社内勉強会で使ったスライドを社外向けに一部加筆訂正したもの
概念から学ぶ正しくRESTfulなAPIとWP REST APIでの実例 #wb_rest
2017.09.03 #wb_rest HANATANI Takuma #wbosaka #wbkyoto #wbnagano 9月のWordBenchの登壇スライドです。
Ruby on Railsチュートリアルを軸にしてWeb周辺技術を勉強した - drilldripper’s blog
最近まとまった時間ができたので、Web開発手法の勉強をしていました。 Ruby on Railsチュートリアルが体系的に学べて良いという話を聞いていたので、これを軸にしながら自分のWeb知識の穴を埋めていくことにしました。 Ruby on Rails チュートリアル：実例を使って Rails を学ぼう 一区切りついたのでまとめておきたいと思います。 前提知識 以下は勉強を始める前の私の知識です。 Webフレームワークを使ったことがない 生PHPなどで開発をしたことはある MVCモデルは一応理解している 昔Java Servletを使った講義を受けたことがある DB Migrationなどの言葉は聞いたことがある Rubyを一行も書いたことがない 普段はPythonとC++を書いている 趣味でJSも少し書く CS的なインフラの基本技術は知っているが、IaaSやPaaSなどにはあまり明るくない
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
REST な API とは何か - ボクココ
以前、こんな REST API を作って欲しいと言われて、その仕様をみたらこの方は本当にRESTの意味をわかっているのかと疑問になる設計だった。意外とRESTって言葉は流行っていても、それが一体なんなのかしっくり来ない方もいるようなので、ここでRESTについて自分なりの理解ではあるがまとめてみようと思う。 REST, それは資源、モノベースのURL 完全に間違えているREST とは例えば以下のようなURL設計だ。 GET /api/listItem GET /api/showItem?id=xxxxx POST /api/createItem POST /api/updateItem?id=xxxxx POST /api/deleteItem?id=xxxxx この場合は、動詞があるのでぱっと見た感じ意味が分かりやすい。アイテム一覧、アイテム詳細、アイテム作成、アイテム更新、アイテム削除。
Retrofit
Introduction Retrofit turns your HTTP API into a Java interface. public interface GitHubService { @GET("users/{user}/repos") Call<List<Repo>> listRepos(@Path("user") String user); } The Retrofit class generates an implementation of the GitHubService interface. Retrofit retrofit = new Retrofit.Builder() .baseUrl("https://api.github.com/") .build(); GitHubService service = retrofit.create(GitHubServ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REST API に疲れたあなたへ贈る GraphQL 入門
RESTfulとは