Paul Prescod の Common REST Mistakes
» Permanent link
|
Paul Prescod の Common REST Mistakes の翻訳版を公開しました。
本当は今年の1月に訳してたんですが、諸般の事情で公開するまでに時間かかってしまいました。また、村田さんからたくさん助言をもらって訳文を修正してあるんですが、それでも Paul の文章は僕には難しくてあんまり読みやすい日本語にはなってません。ただ非常に含蓄のある内容ですのでぜひ原文とあわせてご覧ください。
ラベル: rest, translations
posted by yohei @ 22:53
3 Comments:
2点質問です。
「6.セッションは関係ない。 」に「あらゆるメッセージについて自動的に HTTP 認証は行なわれる。」という記述がありますが、BASIC認証ならOKとかいう話なのでしょうか?
「クライアントアプリケーションは、リソースを使うのであってサービスを使うのではない。 したがって、ログインすべきものは存在しないのだ！」って事ですが、そのリソースを見ていい人といけない人、編集していい人といけない人がいると思うのですが、そういった区別はしてはいけないということでしょうか?
nagasawa さん。
ここはこの文書の中でも一番やっかいなところだと思います。Paul の言うことが絶対正しいわけでもないので、ご自分でご判断ください。
いちおう僕の理解の範囲で説明します。
たとえばある URI を GET しようとしたときに、その URI が指すりソースが誰でも取得可能でなかったら、HTTP のレスポンスコードで 401 が返ります。このレスポンスの WWW-Authenticate ヘッダで認証方式(Basic/Digest, etc)が返りますから、クライアントはその指定された認証方式をリクエストヘッダに加えて再度 GET を試みます。これは HTTP の仕様どおりの動作です。
さて、まず最初のご質問ですが、別に Basic 認証にこだわる必要はありません。Basic でも Digest でも X-WSSE でも認証方式は独立した話です(「Basic 認証ならOK」という意味がわからないので答えになっていないかもしれません)。
二番目のご質問ですが、上記のように各リソースへのリクエストにすべて認証情報が付きます。つまり、アクセス権というのはリソース単位で付けられます。
こんなんで回答になっていますか？
ひとつめの質問は私の書き方がまずかったですね。
BASIC認証に代表されるHTTP標準の認証方法であれば問題ないということですね。HTTP上に独自に認証の仕組みを作るなと。
Javaベースで話をしてしまいますが、HSQLDBを組み込みDBMSとして使い、Tomcatをコンテナとして作る場合は、認証情報を別DBにする必要がありそうですね。その場合ユーザに関することもリソースとして(ユーザの追加などもRESTで)扱おうと思うと、若干苦しそうなのが気になるところです。
２番目については了解しました。
コメントを投稿
<< Home