翻訳: WebAPI 設計のベストプラクティス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さん
JSON Schema で Web API のスキマを埋めよう
クライアント実装 サーバ実装 仕様 Web API にありがちなこと API ドキュメント リクエスト レスポンス ぶっちゃけAPI の追加時く らいしか更新していない なぜかドキュメントにない属性が 含まれている 手が滑ってドキュメントと若干違う形式の 属性を含めちゃったけどなんとなく通った クライアント実装 サーバ実装 仕様 いまは API Blueprint で頑張ってる (http://apiblueprint.org/) API ドキュメント リクエスト レスポンス Markdown の スーパーセット (ツラい) API Blueprint (YAML 表現) generate mock validate あんまり嬉しく ない なんか別に JSON Schema 書かない といけない クライアント実装 サーバ実装 仕様 今日話したいこと JSON Schema API ドキ
RESTful#とは勉強会2はすごかった | いきあたりばったり
先月末にRESTful#とは勉強会2を開催してきました。 これがもう！！！！本当に良かった！！！！勉強になった！！！まだ興奮冷めやらぬ感じです。 勉強会1回目が終わり、得たRESTの知識を私はすぐ実践に生かすことが出来ました。 「これはURLとアクション考えるとControllerもう1個用意する？」なんて会話も出るようになり、レベルアップした感があります。 2回目はどうしようかなとぼんやりしていた時に見た このスライドが大変興味深くて、他にもSlideShareのREST関係も徘徊しましたが、これが一番鷲掴みされました！！！ （レベルが上がってからまた徘徊すると、他の難しいと感じたものにも鷲掴みされるのかもしれませんね。楽しみ。） 「これは皆読むべき！そしてちゃんと理解できるようになりたい！」と思い、「WEBを支える技術」を見返したところ、最後の5部が「WEBサービスの設計」でしたので、
RESTful Web API 開発をささえる Garage (client 編) - クックパッド開発者ブログ
料理動画事業室の @yoshiori です。前に「RESTful Web API 開発をささえる Garage」で紹介した RESTful Web API を開発する Garage のクライアント側のライブラリを公開しました。この記事ではその使い方を紹介したいと思います。Garage の設計思想やサーバ側の実装については上記記事を御覧ください。 今回は簡単にクライアント側の挙動を知っていただくために pry を使って説明したいと思います。 アクセスするサーバは先程の記事で作成したアプリケーションを使用してみます。 サーバの準備 https://github.com/taiki45/garage-example の README にも書いてありますので簡単に進めたいと思います。 まずは下準備としてコードを github から clone してきて、ライブラリのインストールと DB のマイグレ
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
express4でRESTful API作る - yutaponのブログ
ちょっとnode.jsでAPIサーバ作ろうとして express4に上げたらいろいろと使い方が変わっていたので 備忘録的に書いておきます。 expressでのプロジェクトの作り方 ここを見ながらやるのが確実。 https://www.npmjs.org/package/express express3の場合 express3までは $ npm install -g express # グローバルにexpressコマンド入れて $ express appName # expressコマンドでひな形作成 .. $ node app.js # アプリケーション起動 こんな感じでexpressプロジェクトを作れましたが、 express4から結構変更されています。 express4の場合 express4ではひな形を作るコマンドが本体から分離されました。 またアプリケーションの起動方法も変更されて
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に限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ
You don't need API version 2 - yohei's diary
周回遅れ感が半端ないけどバージョニング関連で色々読んで・聞いて思ったことを書く。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight Kazuho's Weblog: 拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima) rest - Best practices for API versioning? - Stack Overflow RESTfulなサービスのバージョンングから得られた知見 RESTとバージョニング 基本的にいわゆる狭義のRESTとAPIのバージョニングは何も関係ない。強いて言えば、HATEOASはバージョニングにも使えるよ、というのがREST信者の主張であるものの、それが正しい（というか実用的）かど
RailsにおけるRESTfulなURL設計勉強会 メモ #sendagayarb - 130単位
zusaar.com - zusaar リソースおよび情報 参加してきました。 以下、粒度にばらつきありますが、気になった点のメモです。ほぼ引用ですが、意図と違う表現になってしまっていたらすみません。 RESTful APIとしてのRailsとクライアントとしてのJavaScript (@ppworks) no title RESTfulの指向で考えると統一されたインターフェースで、URLを見ただけで何するかわかるのが良い JSはassetsのほうに統一しアクションごとに処理が書けるjQuery-Routerなどを使うと良いのでは RailsはだんだんAPI化していくのではないか 通常のHTTPリクエストと非同期HTTPリクエストを同じ統一インターフェースであるRESTfulな設計で管理すると一貫性が出て開発効率の向上につながる リソースモデリングパターンの提案 (@tkawa)
RESTful API Design, Second Edition
This document provides guidance on designing RESTful APIs. It recommends using nouns instead of verbs, keeping URLs simple with only two endpoints per resource, and following conventions from leading APIs. Complex variations and optional parameters should be "swept behind the '?'." The document emphasizes designing for application developers by making APIs intuitive, consistent and complete while
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Adobe Portfolio | Build your own personalized website