タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

webapiとProgrammingとrestに関するbeth321のブックマーク (2)

  • 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リク

  • APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight

    ちょっと前にTwitterAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式(=コントローラ分割)でやってきて後悔したぼくが、(5年ぐらい前から)現在はどうやってAPIのバージョンを管理しているか?について紹介します。 基原理としては、コピペが多発する根っこで分岐(=コントローラ分割)じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー

    APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
  • 1