こんにちは、バックエンドエンジニアのじょーです。大規模なサービスのAPIを開発する際に、ルールを決めずに開発していると無秩序なコードが散見される運用がしづらいAPIになってしまいます。また、ルールを決めたとしても共有が上手くいかないなどの理由で守られなくなってしまうこともあると思います。 本記事では、APIを運用しやすくするために、ただルールを決定しただけではなく、ルールを守るためにそれぞれ仕組み化をしたことを紹介します。 APIのレスポンスを統一する デコレーターを使ってレスポンスの定義を綺麗に書く パラメーターを統一する Validatorによりパラメーターの明記を強制する コーディング規約を守る LinterとSideCIを導入して修正とレビューの自動化 Linterのルールを適度に調節する 1. APIのレスポンスを統一する ここで言うAPIのレスポンスを統一するというのは、返すA
タイトルの通り。 ちょっと調べたらDHHのgistが見つかって、割と良さそうだったのでそれをそのまま使用する事にしました。 # config/routes.rb class ActionDispatch::Routing::Mapper def draw(routes_name) instance_eval(File.read(Rails.root.join("config/routes/#{routes_name}.rb"))) end end Rails.application.routes.draw do draw :api end # config/routes/api.rb namespace :api do namespace :v1 do resources :users, only: %i(index show) end end こんな感じ。 一点問題があって、このままだと
澳门六合官网【官方直营-信誉品牌】澳门六合官网实力打造全网顶级信誉、高赔率、最稳定的娱乐服务平台,24小时客服在线,首充就送,提现秒到账,澳门六合官网欢迎您的加入...
1) The document discusses how Rails realizes RESTful resource modeling patterns through the use of "resources" in config/routes.rb. 2) It argues that focusing on RESTful patterns, including resources, encourages good resource design. RubyGems can also help with resource modeling by implementing specific patterns. 3) If creating a Rails gem, the author recommends designing around resources when pos
こんにちは、鈴木です。 Rails が提供する API の特徴として、引数の指定が柔軟である点が挙げられると思います。 柔軟な引数の指定 例えば、一括代入を許可する属性を指定する attr_accessible メソッドは、以下のように色々な呼び出し方をすることができます。 # 一つだけ指定するパターン. attr_accessible :name # 複数指定するパターン. attr_accessible :name, :email # 複数指定して, さらにハッシュでオプションを指定するパターン. attr_accessible :name, :email, :status, :as => :admin
Two steps for faster browser specs March 11, 2013Posted by Tom Meier Keeping specs fast is a never ending battle for the average Rails developer. There are 2 quick lines of javascript that can make excellent and stable improvements to spec speed performance. Most people are aware of JQuery giving the option to disable animations (see – fx.off), we can disable this in test mode making all browser b
最近Perlで仕事をしていて、cpanfileが無いプロジェクトで盛大にやらかしたtohaeです、こんにちは。 Perlでやらかした経験を生かし、Railsプロジェクトで使うクライアントサイドのJSもちゃんと管理しようとbowerを使うことにしました。 bower is 何? bowerってのはtwitterが作ったJSのパッケージマネージャです。最近紹介記事も多いので、詳しくはぐぐってください。 簡単に言うとJSをwgetする時代は終わったってことです!!! 今回はbowerの紹介ではなく、bowerをRailsで使う場合にはbower-railsを使うといいかもというお話をします。 bower-railsの下準備 まずはbowerをnpmで入れます。 $ npm install bower -g 次にGemfileにbower-railsを追加します。現時点ではバージョンを指定しないと
今日は Rails での『関連モデル』の名前について考える。 構造としてはこんな感じ。 ・ルーム(Room)に所属するユーザー(User) ・ルーム(Room)での管理者権限を持つユーザー(User) どちらの関連も N:N の関連。いわゆる has_may な感じ。 で、こういう時の命名って Room モデルと User モデルだから RoomUser とか UserRoom とかっていうモデルやテーブルを作りがちなのだけれど、今回は同様の形態の関連が2つあるのでちょっと微妙な事になりそう。 っていうか、まずもって RoomUser モデルってなんだよ。なんのモデルだよそれ。って感じなので名前を考える。 ルーム(Room)に所属するユーザー(User) 関連モデルのデータは大抵2つのフィールドを持っている。 Migration あたりから抜き出すと t.references :room
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
Rails4 で、JSON を受け取る API を作りました。 早速、テスト書くぞー!と意気込んだものの、はて。JSON ってどうやって投げればいいんだろう。 いろいろ検索して試してみたものの、うまくいくまで時間がかかったので、メモ。 うまくいったやり方 put :update, user: { name: 'HOGE', mofu: 333, moffu: { mofu: 12, bar: true, foo: 'HI' } }, foobar: true, barfoo: { mofu: 3 }, format: :json assert_equal( 'HOGE', User.first.name ) # params => {"user"=>{"name"=>"HOGE", "mofu"=>333, "moffu"=>{"mofu"=>12, "bar"=>true, "foo"=
I want to DRY up the after create/build hooks in my Factory: FactoryGirl.define do factory :poll do sequence :title do |n| "MyPollTitle#{n}" end sequence :description do |n| "MyPollDescription#{n}" end user factory :poll_with_answers do ignore do answers_count 2 end after(:build) do |poll, evaluator| evaluator.answers_count.times do poll.answers << build(:answer, poll: poll) end end after(:create)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く