タグ

RESTとarchitectureに関するgologo13のブックマーク (5)

  • 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信者の主張であるものの、それが正しい(というか実用的)かど

    You don't need API version 2 - yohei's diary
  • 例えば 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 がある、み

    例えば OSFA な API をやめる - @kyanny's blog
    gologo13
    gologo13 2017/03/01
    各クライアントごとに特化したインタフェースを提供するアダプタ層と、その裏側にあるジェネリックな API との二層構造になっている。
  • 翻訳: WebAPI 設計のベストプラクティス - Qiita

    これは Enchant の開発者である Vinay Sahni さんが書いた記事「Best Practices for Designing a Pragmatic RESTful API」1を、ご人の許可を得て翻訳したものです。 RESTful な WebAPI を設計しようとすると、細かなところで長考したり議論したりすると思います。また、他の API に倣ってやってはみたものの、当にそれでいいのか、どうしてそうしているのか分からない、何てことも少なくはないと思います。 この記事では、そのようなハマリどころについて Vinay さんなりの答えを提示し、簡潔かつ明快に解説してくれています。 今後 WebAPI を設計される方は、是非参考にしてみてください。 なお、誤訳がありましたら編集リクエストを頂けると幸いです。 まえがき アプリケーションの開発が進むにつれて、その WebAPI を公

    翻訳: WebAPI 設計のベストプラクティス - Qiita
    gologo13
    gologo13 2016/03/27
    結構学びあった / スネークケースがbetter / ラップせず返す / pagingはresponse header(Link)に / API major verはURLに、minor ver はheaderに
  • #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

    #mozaicfm REST を聴いての感想 - ぶろぐ。@はてな
    gologo13
    gologo13 2014/11/10
    mozaic.fm REST の会の要点まとめ。Richardson Maturity Model のレベルの話は知らなかった
  • 1