前提・実現したいこと
前提の前提: HTTP等ベースの技術はある程度理解しているつもりですが,Webアプリケーション開発に関しては初心者です.
フロントエンドとバックエンド両方の勉強のため,SPAでブログのようなものを作ってみようと思っています.
ただ自分の記事を表示するだけじゃつまらないので,一般的なブログサービスのようにアカウントを作ってCMS的な機能もつけようと思っています
またAPIに関しては,調べているとよくSPAとセットで出てくるので,REST APIでやってみようと思っています.
疑問に思ったこと
セッションについて
一般的なWebアプリではCookieによってセッションが保持され,「認証済み」のような情報もサーバ側で保持されることになると思いますが,
調べたところ,REST APIはステートレスであり,セッションを保持しません.
作りたいもの的に,「あるアカウントは他のアカウントの記事を削除できない」というようなアクセス制御?も必要になります.
こういう場合には認証を行って,その後はトークンなどを用いて,誰からのリクエストかどうかを確認する必要があるのかなと思うのですが,
この場合,「このトークンはこのユーザのもの」という情報はサーバ側で保持していますが,これは(前後のリクエストとの関係等を示すものではないので)セッションには当たらないという理解で正しいでしょうか?
URLについて
リソースに対して一意にURIが紐づくということですが,例えば個別のユーザが/users/<unique id>
というURIで表されるとすると,
ユーザが自分の情報を変更する場合,REST APIの決まり?的に行くと
PUT /users/<unique id>
このようにAPIにリクエストを飛ばすことになって,同じ「自分の情報を変更する」という操作に対して,ユーザによって異なるURLへのリクエストが発生することになります.
これは,あくまで自分の感覚では,若干直感的でないかなと思ったのですが,「操作」ではなく「リソース」にたいしてURLが割り当てられているREST APIでは通常のことということでしょうか?
またこの場合,クライアント側ではトークンと,(秘密情報には当たらない)自分のunique idを保持する必要があると思いますが.トークンは秘密情報なのでCookieに保存するとして,unique idは認証の際に受け取るとしてどこに保存しておくものなんでしょうか?localStrage等でしょうか
そもそもユーザの情報を変更するのに以下の様なすべてのユーザが同じURLを使うとすればunique idを保持しておく必要はない気がするのですが,どちらが良いのでしょうか?
PUT /user
あなたの回答
tips
プレビュー