Именование конечных точек Rest API для проверки

В API-интерфейсах Rest соглашение, которому следуют конечные точки, заключается в том, чтобы не называть их глаголами, такими как getAllStudents. Но проблема, с которой я столкнулся в последнее время, заключается в том, как обосновать конечную точку проверки. Например, я хочу проверить отпечаток пальца пользователя.

Как назвать конечную точку? Один из способов, о котором я подумал, это POST /user/{id}/verify-fp. Это верно??

Чем я хочу сделать конечную точку, чтобы узнать, заблокирован ли пользователь или нет. Для этого я не могу придумать никакого имени. Обратите внимание, что я не хочу возвращать какие-либо пользовательские данные, которые я просто хочу вернуть, если это правда или ложь, поэтому GET /users/{id} не будет работать для меня.


rest restapi naming
person sarosh    schedule 30.04.2020    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Определенно есть случаи, когда «хороший дизайн REST» не является лучшим подходом для каждого варианта использования. Хотя можно придерживаться соглашений REST и строго рассматривать конечные точки с точки зрения передачи их полного состояния, не использовать глаголы в URI и т. д., боль, связанная с выполнением этого для определенных типов операций, таких как ваша, может быть не стоит.

Подобные конечные точки, безусловно, больше похожи на RPC, и они лучше подходят. Таким образом, использование POST в хорошо названной конечной точке, такой как /user/{id}/verify-fp, кажется хорошим местом для исключения.

person Evert    schedule 30.04.2020

arrow_upward
0
arrow_downward

Для вашего первого варианта использования /fpverification/{id}/verify отлично подойдет. Хотя, если вы используете первичный ключ, более простой способ сделать это:

 fpverification/<int:pk>/verify

Чтобы проверить блокировку, я бы вложил ее в путь пользователя. Таким образом, ваша конечная точка может выглядеть так:

 users/<int:pk>/validate

В качестве альтернативы, если вы часто проверяете статус блокировки, вы можете включить статус true/false в полезные данные пользователя, когда запрос отправляется по исходной ссылке.

person user1881072    schedule 30.04.2020