タグ

restとherokuに関するmanabouのブックマーク (3)

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

  • GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API

    You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

    GitHub - interagent/http-api-design: HTTP API design guide extracted from work on the Heroku Platform API
  • 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