Rails で RESTful Web API をシンプルに保つ設計 - アジャイルSEの憂鬱
Rails で RESTful な Web API を作る場合、色々な方法があると思います。 今回、私が API を作るときによくやっている設計をブログに書いてみます。 コード 説明するより、コードを見てもらった方が早いと思うので、コードを書く。 # config/routes.rb namespace :api, defaults: { format: :json } do namespace :v1 do resource :user, only: :show end end # app/controllers/api/v1/users_controller.rb module Api module V1 class UsersController < ApplicationController before_action :doorkeeper_authorize! def show
RESTfulなWeb APIを設計するときに考えること - Qiita
ApigeeやHerokuのドキュメントに従うのでもよかったんだけど、読んでいく中でやっぱり考えることは出てきたので、あくまで自分のための指針をまとめてます。 包括的なWeb API作成についての知見 HerokuのAPIデザイン | SOTA interagent/http-api-design · GitHub Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト Web API Design | Apigee NetFlixもWeb APIの設計についての知見をよく放出してくれてる印象。 設計の基本 基本は /コレクション/名詞 リソースの関係を表したい時に階層化する members/1234/friends 階層は浅く保つ できるだけ/c
「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
REST API設計者のための有名APIのURL例 - Qiita
