Restfull API, создающий конечные точки

Я пытаюсь организовать конечные точки restfull api, которые мы строим. То, что я до сих пор: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

источник

2016-11-29 Alex

Как вы думаете, что означает «вход» в RESTful API? Какую схему аутентификации вы используете? –

Вот что, я не думаю, что в RESTful 'sign in' можно рассматривать как ресурс. Это скорее функциональная вещь, если я прав. Не совсем понимаю, что вы подразумеваете под схемой auth, мой логин работает следующим образом: член предоставляет электронную почту и пароль, затем создается JWT. У меня также был бы вход в facebook, который будет работать следующим образом: для этого потребуется действительный fb access_token, тогда он создаст JWT так же, как и функция входа. – Alex

Для меня, используя множественном или единственном числе существительных является предметом teaste.

GET /api/members должен разумно возвращать коллекцию членов, а чтобы получить один совершенно смысл использовать либо

GET /api/members/{id} или

GET /api/member/{id}.

Итак, если ваше беспокойство о ресурсе forgot_password было о множественном или единственном виде, не существует «лучшего пути». Тебе решать.

Для регистрации участника, я нашел более целесообразным этот вариант

POST /api/members

потому, что вы на самом деле пытается создать новый member ресурс.

Что касается вашего последнего вопроса, опять же речь идет о том, как вы создаете свой ресурс sign_in. Имеет ли смысл, что sign_in является подресурсом members? Прежде чем дать ответ, обратите внимание на ловушку, включенную в тип ресурса, который вы описываете. Вы уверены, что находитесь задумываясьsign_in как вещь, а не action?

Под этим светом я считаю, что ресурс sign_in будет более естественно размещаться под другим корнем. Однако стоит отметить, что вход в REST немного сложнее. Поскольку srever не разрешено проводить сеанс, вы должны знать, что каждый запрос должен быть аутентифицирован (часто через токен). я не хочу уходить из темы, возможно, вам захочется прочитать this перед тем, как внедрить свой механизм входа.

источник

2016-11-29 20:18:40 MaVVamaldo

Restfull API, создающий конечные точки

ответ

Смежные вопросы