我正在尝试组织我们正在构建的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
事情是我不确定
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
所以我对restfull概念的理解是在资源上使用请求动词。但是当我们拥有/api/members
资源并且我希望有一个端点来登录成员时这是如何适用的?
/api/members/sign_in
或/api/sign_in
或/api/member/sign_in
答案 0 :(得分:1)
对我而言,使用复数或单数名词是一种习惯问题。
GET /api/members
应该合理地返回一个成员集合,而获得一个成员是非常有意义的使用
GET /api/members/{id}
或
GET /api/member/{id}
。
因此,如果您对forgot_password
资源的关注是关于复数形式还是单数形式,那么就没有“更好的方法”了。这取决于你。
为了注册会员,我发现这个选项更合适
POST /api/members
因为您实际上是在尝试创建新的member
资源。
关于您的上一个问题,再次问题是您如何对sign_in
资源进行成像。 sign_in
是members
的子资源是否有意义?在给出答案之前,请注意您所描述的资源类型中包含的陷阱。您确定怀孕 sign_in
作为事物而不是行动吗?
在这种情况下,我相信sign_in
资源会更自然地置于不同的根目录下。
但值得一提的是,在REST中登录有点棘手。由于不允许srever保留任何会话,因此您必须知道每个请求必须进行身份验证(通常通过令牌)。我不想偏离主题,也许你想在实施登录机制之前阅读this。