Edited at

REST: ログアウトAPIのメソッドはPOST?

More than 1 year has passed since last update.

REST APIの設計について、ログアウトAPIのHTTPメソッドについて社内で議論があったので、メモしておきます。

ログアウトといっても連携サービス(OpenID Connectなど)からのログアウトなど、サーバサイドでのユーザ属性の変化など、データ変更を伴うものではなく、単なるセッション切り替えの話です。


結論: 方針

方針としては以下のように決めていくのがいいかと思います。


  • APIが存在しないべき:


    • RESTfulならそもそもセッションのステートはサーバが持っていないはずなので、ログアウトAPI自体が存在しないべき.


    • サーバサイドでDB変更などの処理を行っていないため、クライアントでtoken/sessionの破棄を行えば事足りるはず。



  • DELETE:


    • TokenのrevokeならDELETEだろう.

    • 名前やエンドポイントがlogoutとかでも意味的にはtoken revokeならDELETEがRESTfulか.



  • POST:


    • RESTにこだわらず、ブラウザのprefetch等で勝手にログアウトされることを恐れるならPOSTにすべき.

    • RESTfulではなくなるし、場合によってはAPI一貫性は捨てることになるかもしれない.

    • サーバ側の設計思想というよりもクライアントの仕様を吸収するためのワークアラウンドとしての対応になる.



  • GET:


    • クライアントサイドからクッキー削除するだけなら、サーバサイドの変更がないクライアントのログアウト状態取得APIと割り切ってGETにするのも良い.

    • REST APIと言えなくもなさそう.

    • linkタグに埋め込むケースなど、frameworkによってはブラウザのpre-fetchを誘発してしまう可能性がある.





現状

POSTを採用する、という意見が有力です。

ツールAPIと割り切ってRESTっぽさを残してGET APIにするのも割と好きですが、社内では反論があり、pre-fetchの実害も可能性としてあるため、POSTにしよう、という話になっています。

そもそもそれほどRESTfulにAPIを設計できていないので、RESTらしさを求めるよりも実用性やわかりやすさを重視する方がいいですね。

この辺の妥協というか折衷は重要になるでしょう。


感想

もうぐちゃぐちゃですが、RESTfulの正解、って本当はあまりないのかもしれませんね。

tokenでの認証をベースにしていればDELETEを採用するのが僕は好きです。

(これをきっかけにtokenベースの認証に切り替えたくもあります)

こういう議論は正解がない(or正解では実現が難しい,冗長になりすぎる,わかりづらい,支持を得ない)ことで好き嫌いの問題や実環境の都合になりがちですが、API設計のコンセンサスをとって、選択していけるといいですね。


参考

stackoverflowの議論を中心に。