APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
Web APIの設計指針についての補足｜デロイト トーマツ ウェブサービス株式会社（DWS）公式ブログ
先日初めて、自分が書いたブログの記事、Web API設計指針を考えたがはてブでバズるという経験をしました。たくさんの方に読んでいただけたというのは非常にうれしいことです。ただ、設計指針には根拠を書かなかった箇所が多く補足したいところが出てきたため、以下の内容について根拠などを書いていきたいと思います。 バージョニングについて RESTfulについて バージョニングの設計・実装について 以下の指針を書きました。 APIにはバージョンをつける。 vと整数のバージョン番号をURLにつける。 バージョンは整数。マイナーバージョンは作らない。 例） http://api.example.com/v1/users 上記指針をRailsで実装する場合には、バージョンを上げるときにはコントローラごと分けるようにしています。 ただ、少々前の話になりますが、こんな記事がありました。 APIのバージョニングは限
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信者の主張であるものの、それが正しい（というか実用的）かど
例えば OSFA な API をやめる - @kyanny's blog
OSFA == one-size-fits-all 単一の API で全てをカバーするのをやめたらどうか、ということ。 APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight @kenn 最近はRESTfulなエンドポイントは完全に後方互換なまま、クライアントごとにオーケストレーション層(radical versionin)を設けるという方向にシフトしようとしている。詳しくは http://t.co/zODm7mFr5B— Tatsuhiko Miyagawa (@miyagawa) February 28, 2014 この話のポイントとはちょっとずれてる && Podcast 聴いてないのですが。 Quipper プラットフォームで内部的に利用されている API も、 /v1 というパスの下にはえててごく一部のエンドポイントだけ /v2 がある、み
The Collaborative API Development Platform
New Release - Insomnia 8.0 is finally here with Scratch Pad, Real-Time Collaboration, Enterprise SSO, AI-Generated Testing Design, debug, and test APIs locally or in the cloudChoose Local, Cloud, or Git storage to build better APIs collaboratively with a dev-friendly UI, built-in automation, and an extensible plugin ecosystem. Get Started for Free
HTTPステータスコードを適切に選ぶためのフローチャート : 難しく考えるのをやめよう | POSTD
HTTPステータスコードを返すというのはとても単純なことです。ページがレンダリングできた？よし、それなら 200 を返しましょう。ページが存在しない？それなら 404 です。他のページにユーザをリダイレクトしたい？ 302 、あるいは 301 かもしれません。 I like to imagine that HTTP status codes are like CB 10 codes. "Breaker breaker, this is White Chocolate Thunder. We've got a 200 OK here." — Aaron Patterson (@tenderlove) 2015, 10月 7 訳：HTTPのステータスコードのことは、市民ラジオの10コードみたいなものだと考えるのが好きです。「ブレーカー、ブレーカー、こちらホワイト・チョコレート・サンダー。200
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
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に限らず多様な言語の人に集まってもらえたのがとてもよかったです。 ビ
#mozaicfm REST を聴いての感想 - ぶろぐ。@はてな
mozaic.fmでRESTの回が企画されているということを、API Meetup #1 のときに yohei さんから直接聞いていたのですが、ついにそれが公開されたので、喜び勇んで聴きました。 mozaic.fm #7 REST 断片的に感想をツイートしたので、そのまとめです。 RESTの何が重要なのか さすがの t_wada さん。アーキテクチャとしてもそうだし、アプリケーションフレームワークも「適切な制約」を設けることで設計のコストが下がる、という話の流れでした。 “Constraints are liberating”「制約は自由をもたらす」は僕が好きな言葉ですが、これを知ったのはDHHのRubyKaigi 2006の講演からです。（初出はどこか別のところなのかも？） RESTの流行 原理主義者的発言をするなら、「REST API」と謳って世に出たWeb APIはただのJSON/X
HerokuのAPIデザイン
Herokuが自ら実践しているAPIデザインガイドをGithubに公開した． “HTTP API Design Guide” このガイドは些細なデザイン上の議論を避けて，ビジネスロジックに集中すること目的としている．Heroku特有なものではなく，一般にも十分適用できる知見となっている． 最近は，モバイル向けにAPIをつくることも多いため，勉強もかねて抄訳した．なお内容は，HTTP+JSONのAPIについて基本的な知識があることが前提となっている． 適切なステータスコードを返す それぞれのレスポンスは適切なHTTPステータスコード返すこと．例えば，“成功"を示すステータスコードは以下に従う． 200: GETやDELETE，PATCHリクエストが成功し，同時に処理が完了した場合 201: POSTリクエストが成功し，同時に処理が完了した場合 202: POSTやDELETE，PATCHリク
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
[ThinkIT] 第4回：アーキテクチャスタイル「REST」とは何か (2/2)
ブログを例にとると、Memberが個々のブログのエントリ、Collectionはブログそのもの、Introspection Documentはアクセス可能なブログの一覧、ということになるでしょう。また、カテゴリもCollectionの1つということになります。ブログにエントリを追加する場合は、ブログ（Collection）のURIに対してPOSTメソッドでエントリのデータを送信することになります。同じブログのURIに対してGETメソッドでアクセスすれば、エントリの一覧が取得できます。 そして個々のエントリの取得、編集や削除は、そのエントリのURIに対してGETやPUT、DELETEメソッドを利用してアクセスすることで可能になるわけです。 例えばブログに新しいエントリを投稿するのであれば、そのブログのURI（Collection）に対して前ページのリスト16のようなAtom Feed形式のデ
アーキテクチャスタイル「REST」とは何か
続いて、RESTという考え方について見ていきましょう。RESTという言葉は、例えば「Amazonの商品情報取得APIであるECS（注2）では、SOAPとRESTのインターフェイスが用意されている」といった形で耳にした方も多いのではないでしょうか。この言い方を聞くと、RESTもSOAPと同じようなWebAPIのための仕様であるような印象を受けますが、最初に「考え方」と述べたように、実際には仕様ではなく、Web APIの仕様を決める上でのアーキテクチャスタイル、つまり基本的な考え方ということができます。 ただしここでまず最初に覚えておいてほしいことは、一般的にRESTという言葉は、RESTという言葉が誕生したときの本来の意味で使われる場合と、その後その解釈を拡大して、もっと広い意味で使われるようになったものの2通りがあるということです。例えば前述のAmazonのECSがRESTで提供されている
RESTなWebサービスをPHPで操作する
はてなブックマークのAtomAPIの概要と、アクセスに必要な環境 今回は、「RESTなWebサービスの利用／開発」の第3回として、より本格的にWebサービスにアクセスする例を紹介します。RESTなWebサービスの1つとして、はてなブックマークの「AtomAPI」を例に取り上げ、Web開発用の簡易スクリプト言語であるPHP（PHP：Hypertext Preprocessor）を使ってブックマークの追加／編集／削除を行う方法を解説します。 AtomAPIは、ブログなどのWeb上の情報を、Webアクセスに用いられるHTTP（Hypertext Transfer Protocol）を通して編集するためのプロトコルです。AtomAPIは通称で、正式には「The Atom Publising Protocol」（略称はAtomPub）と呼びます。 AtomAPIでは、一般にはRESTの形式で通信を行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Why I'm putting all my cards on hypermedia APIs at the moment - Sourced Blog
Can a RESTful service return both JSON and XML for the same resource, depending on the request header?
RESTはクラウドにとって重要か
Creating Truly RESTful APIs