API設計【Postモデル】

Fumiya-Matsumoto commented 2 years ago

概要

PostモデルのAPIを設計する

Web API：The Good Partsを参考に「美しい設計のAPI」を作る
目的
美しいWeb APIには以下の利点がある
- 使いやすい
- 変更しやすい
- 頑丈である
- 恥ずかしくない

目的達成のために

以下の原則に従う
- 仕様が決まっているものに関しては仕様に従う
- 仕様が存在していないものに関しては、デファクトスタンダードに従う

参考

Fumiya-Matsumoto commented 2 years ago

Postに関するAPIエンドポイントを修正する

現状①

問題

練習投稿がユーザーIDごとにしか取得できないようになっていて不便	メソッド名	エンドポイント
GET	/v1/users/:user_id/posts(.:format)	v1/posts#index
POST	/v1/users/:user_id/posts(.:format)	v1/posts#create
GET	/v1/users/:user_id/posts/:id(.:format)	v1/posts#show
PATCH	/v1/users/:user_id/posts/:id(.:format)	v1/posts#update
PUT	/v1/users/:user_id/posts/:id(.:format)	v1/posts#update
DELETE	/v1/users/:user_id/posts/:id(.:format)	v1/posts#destroy

解決案

エンドポイントをv1/postsのような形にする

GETに関しては残す。あるユーザーの投稿一覧が一括で取れるのは便利なはず。

修正案

メソッド名	エンドポイント	アクション
GET	/v1/posts(.:format)	v1/posts#index
POST	/v1/posts(.:format)	v1/posts#create
GET	/v1/posts/:id(.:format)	v1/posts#show
PATCH	/v1/posts/:id(.:format)	v1/posts#update
PUT	/v1/posts/:id(.:format)	v1/posts#update
DELETE	/v1/posts/:id(.:format)	v1/posts#destroy
GET	/v1/users/:user_id/posts(.:format)	v1/posts#user_index

備考

練習投稿が特定のユーザーにしか表示、削除、編集できないようにするにはどうしたら良いか調べる
課題②

問題

PostRecordに関するAPIエンドポイントの必要性
現状PostRecordがPostに付随せず、独立に存在することがない
PostRecordはPostを作成する際に付随して作成するため、POST、PATCH、PUT、DELETEメソッドが必要ない
GETに関しては、Postのデータを取得する際に、レスポンスデータに入れればいい
解決案
一旦、削除する

Fumiya-Matsumoto commented 2 years ago

エンドポイントを修正

以下のように修正した。また、postrecordsに関するエンドポイントは削除した。	メソッド名	エンドポイント
GET	/v1/posts(.:format)	v1/posts#index
POST	/v1/posts(.:format)	v1/posts#create
GET	/v1/posts/:id(.:format)	v1/posts#show
PATCH	/v1/posts/:id(.:format)	v1/posts#update
PUT	/v1/posts/:id(.:format)	v1/posts#update
DELETE	/v1/posts/:id(.:format)	v1/posts#destroy
GET	/v1/users/:user_id/posts(.:format)	v1/posts#user_index

修正箇所

config/routes.rbを修正した。

Rails.application.routes.draw do
  namespace :v1 do
    resources :posts
    mount_devise_token_auth_for 'User', at: 'auth'
    resources :users do
      get 'posts', to: "posts#user_index"
      resources :best_times
      resources :objective
    end
  end
end

Fumiya-Matsumoto commented 2 years ago

Postに関するリクエストはログイン中のユーザーにしかできないように設定

before_action :authenticate_v1_userを記述
ここに関して、かなり苦戦したので後でまとめる
Postの作成はログイン中のユーザーにしかできず、かつその投稿はログイン中のユーザーと紐づくようにする
current_v1_userと紐付ける

current_v1_userの情報は、access-token、client、uidをHeaderに記述することで判定する。（トークン認証）

def create
post = @current_v1_user.posts.build(post_params)
if post.save!
    render json: {
         post: post
    }, status: :created
else
    render json: {}, status: :internal_server_error
end
end

Fumiya-Matsumoto commented 2 years ago

トークン認証について

認証方式には、Cookie（Session）による認証方式とTokenによる認証方式がある。

Cookie（Session）による認証方式

Cookieは、Webサーバーがクライアントに預けておく極小なファイルのことをさす。クライアントがWebサーバーに初めて接続（Login）した際に、Webサーバーがクライアントに対してCookieファイル（SessionID）を発行し、HTTPレスポンスのヘッダを利用して送る。その際に発行されたSession情報（SessionID）にはログイン情報が含まれる。次回以降、クライアントがWebサーバーにアクセスした際は、リクエストヘッダに含まれるCookie（SessionID）をサーバーが参照し、実際にサーバーに保存されているSession情報と合致した際に認証されたとみなされる。

Tokenによる認証方式

Tokenによる認証も、Cookieと同じく、まずはクライアントがWebサーバーに接続（Login）した際に、Tokenが返される。ただ、ここで違うのは、サーバーにその情報を保存はしない。「認証に成功した」というToken（いわゆる「認証情報」）を持ち、リクエストする度にリクエストヘッダにTokenを含んで送る。

参考

以下の記事を参考に実装したら、認証が実現できた！ Rails6.0とdevice_token_auth でトークンベースで認証を実装する~confirmable + action mailerの設定まで

Fumiya-Matsumoto commented 2 years ago

参考になりそうな記事

【Rails】devise_token_authでToken認証を実装する

Fumiya-Matsumoto commented 2 years ago

課題

現状、ある投稿の編集、削除がログインしているユーザーであれば誰でもできる状態にあるため、その投稿を作ったユーザーにしかこれらが行えないようにしたい。

解決

current_v1_user.id == @post.user_idのときにしか投稿の編集・削除が行えないようにした。

      def update # 現在ログイン中のユーザーの投稿であれば編集可能
          if current_v1_user.id == @post.user_id
              @post.update(post_params)
              render json: {}, status: :no_content
          else
              render json: {}, status: :forbidden
          end
      end

      def destroy # 現在ログイン中のユーザーの投稿であれば削除可能
          if current_v1_user.id == @post.user_id
              @post.destroy
              render json: {
                  post: @post
              }, status: :no_content
          else 
              render json: {}, status: :forbidden
          end
      end

Fumiya-Matsumoto commented 2 years ago

トークン認証に必要なuid、client、access-tokenをどう取得して、クライアントに保持させるかがまだ不明瞭だが、以下の記事が役に立ちそう。クライアント側を作る際に参考にする。

access-token これはリクエスト毎にユーザーのパスワードとして提供されます。この値のハッシュ・バージョンは、後で比較するためにデータベースに保管されます。この値はリクエスト毎に変更されるべきです。 client これにより異なるクライアント上で複数の同時セッションを管理することができます。たとえば、携帯電話とラップトップの両方で同時に認証を受けたい場合があります。 expiry 現在のセッションが失効になる日にちです。これは、クライアントがAPIリクエストを必要とせずに期限切れのトークンを無効にするために使用できます。 uid ユーザーを識別するために使用される一意の値。アクセストークンでユーザーのDBを検索すると、APIがtiming attacksを受けやすくなるため、これが必要です。

参考記事

【React】＋【RailsAPI】アプリ [4] ユーザー認証（devise/devise_token_auth/redux-token-auth）_後編

Rails の devise_token_auth と Next.js でログイン処理

【Rails】devise_token_authでToken認証を実装する

Rails API(devise_token_auth)＋Reactでのログイン時のメール本認証(comfirmable)実装

Fumiya-Matsumoto / run_manage_spa