Best practices for API versioning?
This is a good and a tricky question. The topic of URI design is at the same time the most prominent part of a REST API and, therefore, a potentially long-term commitment towards the users of that API. Since evolution of an application and, to a lesser extent, its API is a fact of life and that it's even similar to the evolution of a seemingly complex product like a programming language, the URI d
Automatically generate Angular resources for your Rails API
Rails & Angular Part I Posted on May 7th, 2014 by Ewout Kleinsmann We are a young web agency, founded April last year. Kohana (PHP framework) together with SpineJS (Backbonesque JS framework) had always been our development stack of choice, but we were looking for something new. After some research we picked Ruby on Rails in combination with AngularJS and we started the development of our own CMS
HerokuのつくってるAPI関係の便利なやつ - ✘╹◡╹✘
JSON Schema for the Heroku Platform APIでも紹介されているように、HerokuのAPIはJSON schemaで記述されたAPIの仕様を返すようなAPIがあって(ややこしい)、Auto-generating a Go API client for Herokuのようにこれを利用してAPIクライアントを自動生成するようなこともやってる(単なるアート作品じゃなくて実際に運用されているので偉い)。Herokuが出してるAPI関連作品の1つにcommittieというのがあって、JSON schemaを利用してAPIの仕様を定義して、それをRack middlewareで利用しようというもの。前に試しに似たようなのつくってたので良いのが出てきて良かった。 Committieは大きく分けて3種類の機能を提供していて、1つは本番環境で普通に使うやつで、リクエストをv
WebSockets now Generally Available
WebSocket support was introduced as a Labs feature last year, and we went through extensive testing and a number of technical iterations to improve performance and to provide a predictable compliance target. Thanks to great interaction with the community and early feature users, we now have a fast and robust solution available in production. Why WebSockets WebSockets provide bi-directional and ful
API Meetup Tokyo #1 参加レポートとAPIをいい感じに扱うためのサービスたち #apijp
7月11日（金） ●API Meetup Tokyo記念すべき第1回目！ API Meetup Tokyoというイベントに参加してきました。 スマホとアプリの爆発的な普及をきっかけに、サービスバックエンドのWeb API化が急速に進んでいます。この動きは単なる内部実装に留まらず、企業がビジネスをAPI化してネット上に展開する、という大きな流れを生み出しています。 API Meetupは、Web APIに携わる開発・企画担当者が、APIまわりのさまざまな要素技術や適用事例を一緒に学ぶオープンな勉強会です。 （http://api-meetup.doorkeeper.jp/events/12768より） とのことで、APIを活用した開発に関わる一エンジニアという立ち位置で参加してきました。 今回は第「1」回ということで今後も続くとのこと。 最初の数回はセミナー形式、その後ハンズオンで実際に何か
拡張可能なWeb APIの設計原則と、バージョン番号を使う理由について
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sightにはブコメしたのですが、Rebuild: 35: You Don't Need API Version 2 (Kenn Ejima)でも本件に言及があったようなので、少し一般論を書いておきたいと思います。 ■Web APIの設計原則について そもそも、良いAPIとはどのような特性をもつものでしょうか？ 一般的に、以下の２点が挙げられると思います。 拡張が容易である 拡張時に後方互換性を破壊しない ウェブの場合は、これに加え、 スケーラブルである HTTPに起因する問題に上手に対処できる ことが求められます。 前２者はウェブに限らない要件です。これを満たす設計手法としては、 リクエストおよびレスポンスのパラメータを拡張可能に 互換性を壊す拡張が必要な場合は、関数名を変える 古い関数は従来と同じ機能を
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信者の主張であるものの、それが正しい（というか実用的）かど
Best Practices for Designing a Pragmatic RESTful API
Your data model has started to stabilize and you're in a position to create a public API for your web app. You realize it's hard to make significant changes to your API once it's released and want to get as much right as possible up front. Now, the internet has no shortage on opinions on API design. But, since there's no one widely adopted standard that works in all cases, you're left with a bunch
API設計のポイント - ワザノバ | wazanova
Living Socialが7回に渡りSOA (Service-oriented architecture) についてのブログを書いてますが、今回はAPI設計についてのエントリーです。 「APIはRESTful」と言うだけでなく、社内でガイドラインがオーソライズされるように調整すること。設計にあたっての選択肢及び自由度をしっかり考慮すること。そして一番大事なのは、決めた原則とおりにブレなくインプリすること。 どのHTTPステータス（success/error）をどのシチュエーションで採用するか。 204もしくは200をPOSTで使うか？PUTで使うか？ 4xx番台のコードの一貫性。 bodyにエラーメッセージを追加するのか。 認証はどこで？ ヘッダー？もしくはURLパラメータ？ リソースの階層はどうするか。 忠実にRESTfulとするのか、RPCのようなエンドポイント（/inventory
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Bitbucket
Lingr Bot API