APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
マイクロサービスバックエンドAPIのためのRESTとgRPC
1. The document discusses RESTful APIs and gRPC, comparing their characteristics and use cases. 2. RESTful APIs typically use HTTP and JSON to access resources via URLs while gRPC uses protocol buffers and HTTP/2 for efficient streaming and RPC. 3. gRPC is better suited for microservices and mobile apps due to its ability to handle streaming and performance, while REST is more widely used due to i
HTTP API の設計方向
見てみると、たしかに Get 系の API だとしても POST を利用しているし、API の URL 設計に get_shared_link_file のようによく言われる REST っぽい設計は使っていなかった。 この方針は同意だ。自分は結構前に REST っぽい API を捨てることにした。だからといって REST API がダメだとかは思っていない。 一般ユーザが使う場合の API は REST API であるほうが慣れ親しんでいる場合が多いからだ。 AWS で利用されている HTTP API 仕様AWS の DynamoDB の Erlang/OTP ドライバーを書いているときに気づいたのだが、AWS の一部のサービスはかなり独特な API の仕様になっている。
翻訳: WebAPI 設計のベストプラクティス - Qiita
これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご本人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、本当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公
MisocaのiPhoneアプリのためのAPI開発 - 弥生開発者ブログ
こんにちは、開発チームのmzpです。MisocaのiPhoneアプリがリリースできて、ほっとしています。 www.misoca.jp 今回は、このiPhoneアプリ用のためにつくったAPIについて書きたいと思います。 提供するAPIの種類 MisocaではすでにAPIv1と呼ばれるRESTful APIの提供を行なっています。 しかし、iPhoneアプリ開発では、以下のような理由から、APIv1を拡張するのではなく新規にAPIを作成することにしました。 通信回数をなるべく減らすため、1回のレスポンスに必要な情報を詰めたい 汎用のAPIではなく、iPhoneアプリの特化したAPIを作りたい iPhoneアプリから使わない機能の実装・テストは省略したい このように特定のアプリケーション向けのAPIのことをSSKD (small set of known developers)*1 と呼ぶそうで
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
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リク
Reverb.com Dev Blog | HAL, Siren, Rabl, Roar, Garner: Building Hypermedia APIs in Ruby/Rails
10 months ago by reverbyan-deactivated20131219 Untitled | Notes: 1 Why build Hypermedia APIs? This week we started to build out the Reverb API. Being a greenfield project, we decided to investigate the best practices for building truly RESTful (that is, Hypermedia-based) APIs. The key takeaway for such APIs is that no out-of-band knowledge is passed between the server and the client (meaning bas
APIのドキュメントを書くためのフレームワーク・「Swagger」
SwaggerはAPIのドキュメントページを作る為のフレームワークです。細かい仕様や使い方などをユーザーに分かりやすく伝えられるように設計している様です。こういったフレームワークはあまり見かけないので、ドキュメントの作成が捗ると良いですね。ライセンスは Apache Ver 2との事です。 Swagger
Web API 設計のベストプラクティス集 "Web API Design - Crafting Interfaces that Developers Love" - フリーフォーム フリークアウト
移転しました http://please-sleep.cou929.nu/20130121.html
Qiita APIが第３者のアプリケーションに提供されるときにはOAuth 2.0で実装されることを願う - r-weblife
こんばんは、ritouです。 今日はTwitterでQiita APIにつっかかりそうになったのでその中で考えたことを残しておきます。 QiitaAPIを公開しました！ - Qiita Blog Qiita API v2 documentation - Qiita:Developer Qiita APIの仕様に対する懸念点 - Togetter(10/10 22:18追記) はじめに思ったこと 個人の投稿の作成/更新/削除までさせるんだな さすがにその時はTokenを使うんだな Tokenはユーザーの識別子(Twitter/Github)とパスワード(Qiita上で設定)で取得か で、 なぜOAuthでやらないのか という感じです。 仕様確認 んで、TLで中の人じゃない人と話して仕様について以下のような指摘を受けた。 QiitaにログインするのはTwitter/GithubのOAuthであ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
JSON APIと�フォーマットの話
API design for an event-driven world | George Ornbo
WEB APIのURL設計のトレンドはこれだ！WEB APIのURL設計まとめ
TechCrunch