REST関連と認証トークンについて

勉強記録

今日は「Webを支える技術」を読んだのですが、第1部のWeb議論に「REST」について書かれていました。

RESTと認証トークンについて、様々な記事を読んで追加で勉強しました。

APIのバージョニング

APIにはバージョンをつける。

API自体のバージョンを変えることもあるが、いきなり全部のバージョンを変えることはない。

アプリにもバージョンがあるし、APIにもバージョンがある。少しずつ新しいバージョンのAPIにしていく。

 

HTTPステータスコードを適切に選択するには

RESTfulなWebサービスを実現するには、処理結果はステータスコードで表現すべきと言われている。

理由としては

・適切なHTTPステータスコードを返さないと、わざわざエンティティの中を解析しなければ処理結果が判別できない。

・HTTPステータスコードから処理結果がどうだったのか理解しやすい。

 

しかし、どういったときにどのステータスコードを使うのか迷う時がある。

HTTPステータスコードのフローチャートがあるので、調べて見てみるとわかりやすい！

（参考サイトはこちら）

www.agilegroup.co.jp

 

必ずしもRESTでないといけないのか

GoogleのガイドラインでもRESTfulなURLにしよう！となっているが、RESTは設計も複雑で難しく、素晴らしいけども完璧ではないし反対派もいる。（RESTfulとはREST の制約に従っていてRESTらしいということ）

RESTじゃない設計を考えている人もいる。（より柔軟なGraphQLやJSON-RPC)

現場によって設計が違うから、設計方針は知っておく必要がある。

 

認証トークン

トークンを利用して認証・認可するしくみの一部としてAuthorization: Bearerヘッダを使うことができる。

このヘッダの仕様はRFC6750で定められている。

OAuthの仕様の一部だけど、一般的なHTTP認可の手段として使える。