смущен тем, как API CRUD должны быть разработаны для различных подходов к аутентификации

#javascript #rest #http

#язык JavaScript #остальное #http

Вопрос:

Я знаю, что существует в основном два подхода к аутентификации — сеансы и токены. И для сеансов, я думаю, идентификатор сеанса обычно хранится в файле cookie, который отправляется вместе с каждым последующим запросом. А для токенов, например JWT, обычно это строка, добавляемая в заголовок авторизации с префиксом bearer в заголовке HTTP.

Мой первый вопрос: для API, которые интерфейс использует для выполнения CRUD на защищенных ресурсах от имени вошедшего в систему пользователя, должны userId быть частью подписи API. Другими словами, должны ли разработчики интерфейса передавать userId данные, когда они совершают эти вызовы API? Например, у меня есть конечная точка api для обновления ресурса

 UpdateTask(userId?: string, taskId: string, updatedTaskConfig: TaskConfig): Task - POST /v1/tasks/:id  

Следует ли нам опустить userId , поскольку идентификатора сеанса или токена (зависит от выбранного нами подхода к аутентификации) будет достаточно, чтобы серверная часть определила, от какого пользователя отправляется этот запрос? Или нам все еще нужно включить его?

Другой связанный с этим вопрос заключается в том, что я знаю, что как JWT, так и идентификаторы сеанса могут быть отправлены несколькими способами (файлы cookie, заголовки, тела запросов, URL-адреса и т. Д.). Влияет ли это на API при включении userId ?

Мой второй вопрос заключается в том, для любой операции CRUD, должны ли вызовы API включать timestamp сгенерированный на интерфейсе? Или он должен быть сгенерирован на серверной части, поскольку вызовы api могут завершиться неудачно по ряду причин, так что имеет смысл позволить серверной части сгенерировать метку времени?