Restfull APIの構成エンドポイント

Question

私が構築しているrestfull APIのエンドポイントを整理しようとしています。私はこれまで持っていることは次のとおりです。

GET - /api/members/list 

GET - /api/members/:member_id 
PUT - /api/members/:member_id 
DELETE - /api/members/:member_id 
POST - /api/members - add member 

POST - /api/member/forgot_password 
POST - /api/member/reset_password 
POST - /api/member/sign_up - this is same as - POST - /api/members - add member 
POST - /api/member/sign_in 
POST - /api/member/validate 

POST - /api/member/auth/twitter 
POST - /api/member/auth/gplus 
POST - /api/member/auth/facebook 

事は、私はので、私はrestfullの概念について理解してどのようなリソース上で要求動詞を使用することです

POST - /api/members/forgot_password 
OR 
POST - /api/member/forgot_password 

//For register a member to use post over resource 
POST - /api/members 
OR 
//To have endpoit for that 
POST - /api/member/sign_up 

については確認していないということです。しかし、/api/membersリソースがある場合、これはどのように当てはまるのですか？私はログインメンバーのエンドポイントを持っていますか？複数または単数の名詞を使用して

/api/members/sign_inまたは/api/sign_inか私には

Answer 1

/api/member/sign_inは、teasteの問題です。 1は

GET /api/members/{id}または

GET /api/member/{id}のいずれかを使用することは完全に意味がある取得する一方、

GET /api/membersは、合理的にメンバーのコレクションを返す必要があります。

forgot_passwordリソースに関する懸念が複数形または単数形についてのものだった場合、「良い方法」はありません。それはあなた次第です。

メンバーを登録するために、あなたが実際に新しいmemberリソースを作成しようとしているので、私は、このオプション

POST /api/members

より適切ない。

あなたの最後の質問については、もう一度あなたのsign_inリソースをイメージングする方法の問題です。 sign_inがmembersのサブリソースであることは意味がありますか？答えを与える前に、あなたが記述しているリソースの種類に囲まれたトラップに注意してください。 sign_inをのものとしての動作ではなくと考えていますか？

このような観点から、sign_inリソースは、より自然に別のルートの下に配置されると考えられます。 しかし、RESTでのログインはちょっと難しいことに言及する価値があります。 sreverはセッションを維持できないので、毎に要求を（多くの場合、トークンを介して）認証する必要があることに注意する必要があります。私は話題から外れたくありません。サインインの仕組みを実装する前に、thisを読んでみたいかもしれません。