ОТЛИЧНАЯ лучшая практика. Нарушает ли это ограничение без гражданства?

Question

У меня есть конкретный пример того, как оставаться верным принципам RESTful, а именно:

Без сохранения состояния: Один клиент может отправить несколько запросов на сервер; однако каждый из них должен быть независимым, то есть каждый запрос должен содержать всю необходимую информацию, чтобы сервер мог понять это и обработать его соответственно. В этом случае сервер не должен содержать никакой информации о состоянии клиента. Любая информация статус должен оставаться на клиенте - например, сеансы. (цитата из: https://www.dineshonjava.com/what-is-rest-and-rest-architecture-and-rest-constraints/)

Теперь предположим, что пользователь может создать новое событие, разместив это:

{
  "name": "string",
  "radius": 50,
  "status": 0,
  "location": {
    "lat": 0,
    "lng": 0
  },
  "commonUserId": 0
}

Приложение настроено так, что пользователь может выполнить то же самое, разместив вместо этого:

{
  "name": "testing",
  "radius": 50,
  "status": 0,
  "location": {
    "lat": 0,
    "lng": 0
  }
}

Обратите внимание, что commonUserId отсутствует во втором примере. commonUserId - это внешний ключ в БД, необходимый для создания новой записи.

Причина, по которой это не требуется для создания новой записи, заключается в том, что приложение использует маркер доступа, предоставленный клиентом, для получения идентификатора пользователя (идентифицированного идентификатора пользователя) с использованием некоторой логики. Затем приложение использует этот извлеченный идентификатор (из логики) для создания вставки / записи.

Теперь мой вопрос: это нарушает ограничение без сохранения состояния успокоительного API?

Я могу аргументировать оба способа:

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

Да это нарушение, потому что клиент зависит от логики приложения для получения идентификатора пользователя. Приложению пришлось искать идентификатор пользователя, а не клиент, отправляющий его.

Причина, по которой я спрашиваю это, заключается в том, что я могу сделать идентификатор частью информации, которую должен предоставить клиент, однако, поскольку требуется accessToken, приложение может использовать это для получения идентификатора ...

Может быть, я слишком много думаю об этом? Что такое лучшая практика? Это до разработчика это ситуация? Кто-нибудь еще сталкивался с этой проблемой? Как бы вы справились с этим и почему?

Примечание: я строю это с помощью LoopBack.

Редактировать:

Итак, я полагаю, здесь есть основной вопрос. Можно ли полагаться на токен доступа в качестве средства для получения другой информации?

Answer 1

Теперь мой вопрос: это нарушает ограничение без сохранения состояния успокоительного API?

Окончательное определение безгражданства (в контексте REST) ​​взято из третьей главы диссертации Роя Филдинга, где он описывает Клиент-Состояния-Сервер Иерархический стиль

Стиль client-stateless-server является производным от client-server с дополнительным ограничением, состоящим в том, что на компоненте сервера не допускается состояние сеанса. Каждый запрос от клиента к серверу должен содержать всю информацию, необходимую для понимания запроса, и не может использовать какой-либо сохраненный контекст на сервере.

... Масштабируемость улучшена, поскольку отсутствие необходимости сохранять состояние между запросами позволяет компоненту сервера быстро освобождать ресурсы и еще больше упрощает реализацию.

Глава 6 тезиса Филдинга, где он обсуждает сеансовые куки , описывает часть проблемы сохранения состояния сеанса на сервере.

Когда функциональность истории браузера (кнопка «Назад») впоследствии используется для резервного копирования представления, предшествующего тому, которое отражено в файле cookie, состояние приложения браузера больше не соответствует сохраненному состоянию, представленному в файле cookie. Поэтому следующий запрос, отправленный на тот же сервер, будет содержать файл cookie, который искажает текущий контекст приложения, что приводит к путанице с обеих сторон.

Таким образом, вы можете использовать информацию в теле сообщения и использовать «логику приложения» для ее преобразования. Точно так же вы можете использовать информацию в заголовках сообщений и использовать «логику приложения» для ее преобразования.

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

Можно ли полагаться на токен доступа в качестве средства для получения другой информации?

Это зависит?

"Этот запрос включает токен доступа 12345, поэтому commonUserId должен быть 67890, потому что это всегда верно для токена 12345". Это должно быть хорошо.

"Этот запрос включает в себя токен доступа 12345, поэтому commonUserId должен быть 67890, поскольку ранее был запрос с токеном 12345, который велел нам использовать commonUserId 67890" <- без сохранения состояния. </p>

У Кристофера Сандовала есть хорошее эссе о с отслеживанием состояния и веб-службами без учета состояния , которые могут помочь прояснить ситуацию для вашего случая.

Answer 2

Я думаю, что вы смешиваете две вещи - запрос аутентификации и запрос данных.

Токен доступа обеспечивает обработку данных запроса, если токен действителен.

Тогда бизнес-логика вашего приложения отвечает за интерпретацию данных запроса, сопоставление их с вашей моделью данных и решение, что использовать в качестве идентификатора пользователя при создании события. Представьте, что токен доступа просто идентифицирует пользователя Admin как отправителя запроса, а данные запроса содержат идентификатор пользователя Boy как commonUserId, для которого событие создается по запросу.

Использование токена доступа для идентификации пользователя является обычной практикой для loopbackjs framework.

Answer 3

Вы не задумывались. Это действительно здорово, что вы помните об этом при написании кода. Кто-то через несколько лет на самом деле поблагодарит вас за принятие правильных решений, когда они смотрят на код.

Теперь перейдем к теме. На вашем месте у меня не было бы "commonUserId", и я говорю это с точки зрения безопасности. Потому что я должен был бы проверить значение commonUserId в любом случае, чтобы увидеть, существует ли оно в моей системе впервые (не доверяйте вводу клиента) или оно действительно принадлежит аутентифицированным пользователям (маркер доступа в вашем случае). Поэтому по этой причине я бы покончил с этим и использовал бы токен доступа и логику приложения для идентификации пользователя.

Дело может быть сделано в любом случае действительно, но убедитесь, что вы не доверяете слепому вводу клиента, даже если приложение устанавливает это значение в первую очередь.

Удачи!