Rest API и UUID

Question

Одна из причин, и, возможно, главная, использовать UUID - избежать «централизованной» точки, ответственной за создание и назначение идентификаторов ресурсам.

Это означает, что для API REST клиенты могут (и должны) иметь возможность генерировать и предоставлять UUID для определенного ресурса, когда они впервые отправляют этот конкретный ресурс. Это свести к минимуму проблемы, связанные с успешной публикацией ресурса в первый раз, но не вернуть идентификатор в качестве ответа (например, проблемы с подключением). Это может привести к появлению новой должности для некоторых клиентов, генерируя дублированные ресурсы.

Мой вопрос являются:

• После UUID порождена клиентов и подвергаясь в REST API является наилучшей практики?
• Есть ли другие альтернативы этому?

Answer 1

REST на самом деле не заботится, генерируется ли UUID сервером или клиентом. Ему просто нужен уникальный идентификатор ресурса в виде URI. Какая форма URI имеет, не важна для клиентов и серверов - только они уникальны и могут быть получены клиентами (HATEOAS). Разумеется, вам также нужен ресурс на стороне сервера, который может создать для вас под-ресурс и понимает, что вы хотите предоставить UUID вместо создания собственного. Вместо UUID вы могли бы f.e. также используйте заголовок заголовка блога-сообщения или подобный этому вопросу комбинацию хеш-значения и вопрос-заголовка 31584303/rest-api-and-uuid, чтобы однозначно идентифицировать ресурс.

Создание UUID клиентом, по-моему, не используется на практике, но я могу ошибаться в этом вопросе. Фактический вопрос заключается в том, почему клиент должен действительно предоставлять собственный UUID вместо того, чтобы позволить серверу создать его? Клиент, IMO, заинтересован в получении данных на сервере и имеет некоторый способ получить его в какой-то более поздний момент, который будет предоставлен через заголовок местоположения, возвращенный в ответ запроса POST.

Если проблемы с подключением являются актуальными, вы можете позволить клиенту отправить пустой POST для создания ресурса и отправить обратно местоположение в заголовке. Содержимое добавляется через запрос PUT.

Там еще могут быть некоторые проблемы с соединением, связанные:

• запрос не достигнет сервера
• ответ не доходит до клиента

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

У сервера может быть поток очистки в задней части, который удаляет пустые ресурсы через определенное количество времени. Если клиент отправляет дополнительный пустой запрос POST, но на этот раз также получает URI созданного ресурса, он может обновить состояние ресурса через PUT. PUT является идемпотентным. Если сервер не получил запрос, клиент может просто его просить. PUT имеет семантику обновления существующего или создания нового ресурса, если он еще не доступен. Таким образом, сервер может создать ресурс в этом случае с предоставленным контентом. Если запрос дошел до сервера, дальнейшее обновление не изменит состояние ресурса.