Validating REST queries with Rails (Example)
I've recently been working on a few RESTful API's using Rails. One of the problems that I keep seeing with end users is that they usually don't read the documentation very well and make simple mistakes when making specific requests and queries. This is easily solved with error handling and validation of the API. There are a few gems out there that will handle this sort of situation for you, but th
Ruby on Rails で Web API のパラメータをバリデーションする｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
MMMの前田です。 早いもので、MMMに入社してから1年が経過しました。 振り返ってみると、この1年はほぼRuby on RailsでWeb APIを作っていました。 常にRailsに触れることが出来、非常に楽しい一年になりました。 本日はRuby on Rails の Web APIで、クライアントからのパラメータをどのようにチェックしてバリデーションをしているかを纏めてみました。 ruby version 2.2.2 Ruby on Rails version 4.2.2 何故WebAPIのリクエストパラメータのバリデーションが必要なのか 例えばバリデーション無しでパラメータを受け取った場合、以下のコードでパラメータによって期待しない結果になったりします。 Book.where(id: params[:book_id]) 上記のコードはActiveRecordの基本的な検索パターンです
RailsでAPIを作るときにいちいちエラーのレスポンス作るのがだるい話 - 鳩舎
なんかアクションで def index begin ... rescue => e render :json => e end end みたいにしてんのがだるいので設定する。 ApplicationControllerで class ApplicationController < ActionController::Base rescue_from Exception, :with => :error_render private def error_render exception = $! respond_to do | format | format.json { render :json => e } end end end とか設定しておくと、raiseしたときに拾ってよしなに出してくれる。
RESTful APIのエラー設計 - Qiita
RESTful APIのレスポンスデータ設計の最後でも述べたが、APIでエラーが発生した時のレスポンスデータも検討する必要がある。 エラー発生時のレスポンスデータの考え方 APIのレスポンスデータはほとんどの場合プログラムで処理されるため、エラーが発生した時も、 どんなエラーが発生したのか そのエラーはなぜ発生したのか そのエラーはどうすれば解決できるのか をプログラムが分かるようにしておく仕組みが必要。 エラー発生時のレスポンスデータ 1. HTTPステータスコードの設定 エラーが発生したら、レスポンスボディにエラー情報を設定するだけでなく、(RESTful APIのHTTPステータスコード設計でも書いた通り)適切なHTTPステータスコードを設定する必要がある(エラーが発生しているのに200を設定したりしないこと、200はリクエストが成功した時のみしか返してはいけない)。 2. レスポン
WebAPIでエラーをどう表現すべき？15のサービスを調査してみた - Qiita
2017-01-05 追記 2016年3月にエラーの標準形式RFC7807「Problem Details for HTTP APIs」が提案され、今日現在proposed standard(標準化への提唱)となっています。こちらも是非ご覧ください。 RFC 7807 - Problem Details for HTTP APIs HTTP APIの詳細なエラー情報をレスポンスに持たせるための仕様 最近はREST APIを提供しているサービスが増えてきていますね！また公開されるAPIだけでなく、Microservicesなアーキテクチャを採用して、バックエンドがWeb APIで通信するケースも増えてきているように思います。 APIを使うときはあまり気にしたこともなかったですが、いざAPIを設計してみるとどんなインターフェイスがいいのか、どんな形式がいいのかといった疑問が次々と出てきます。
無料WordPressテーマ「Cocoon（コクーン）」を公開しました
SEO・高速化・モバイルファースト最適化済みのシンプルな無料Wordpressテーマ。100％GPLテーマです。 以前公開したSimplicityの後継となるテーマです（※後釜ということで完全な互換性はないです）。 新しくテーマを作成したのは、Simplicity自体元々、個人用に作成したものを公開したテーマだったので、機能を増設するにつれて、多少の無理も出てきて、動作確認が大変になってきたからです。 また、Simplicityは、約4年前に公開したものなんですが、「当時のWEB状況」と「最近のWEB状況」に乖離もでてきました。ですので、一度現在の状況に合わせて作り直しておきたかったからです。 元々Simplicity自体、僕が初めてPHPで作成したプログラムだったので、当時はPHPの作法などをよくわかっておらず、書き直したい部分もいろいろ出てきたというのもあります。 こういった複合的な理
デザイナーを伸ばす過程で大切にしたこと｜Nobuo Suzuki
1年目のデザイナーに教えたほうがいいことや、デザイナーを育てるとはどういうことなのか。 自分のことはどうにかなってきた20代中盤。「デザイナー育ててね」と突然言われても何から始めればいいのかもよく分からなかったですし、どうやってアドバイスしたらいいかも分からなかった当時、デザイナーの育成に関する記事があまりに少ない印象だったので、同じような境遇の方の役にたてば嬉しいです。 ※この記事は、2017年4月にMediumで公開した記事を加筆・転載したものです。*** 本人が課題を感じて初めて成長するWe don't know what we don't know. （分からないことが分からない。）突然ですが、他人に言われた時よりも自分で課題を認識できた方時の方が腹落ちしませんか？ 教える側は、相手が分かっていないところが分かるのですが、当の本人は「分からないことが分からない」状態なのです。でも、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
