Идемпотентность глагола GET в RESTful API

Как упоминалось здесь https://restfulapi.net/http-methods/ (и в других тоже места):

API-интерфейсы GET должны быть идемпотентными, что означает, что выполнение нескольких идентичных запросов должно давать один и тот же результат каждый раз, пока другой API (POST или PUT) не изменит состояние ресурса на сервере.

Как сделать это верным в API, который, например, возвращает время? или которые возвращают данные, на которые влияет время.

Другими словами, каждый раз, когда я использую GET http://ip:port/get-time-now/, он будет возвращать другой ответ. Однако я не отправлял никаких POST или PUT между двумя последовательными GET's

Делает ли это предыдущее утверждение неверным? Я что-то неправильно понял?


person Humam Helfawi    schedule 21.03.2018    source источник


Ответы (1)


Идемпотентность — это обещание клиентам/посредникам, что запрос может быть повторен в случае сетевых сбоев или тому подобного без каких-либо дополнительных соображений и не столько в том, что данные никогда не изменятся.

Например, если вы возьмете запрос POST, в случае сбоя сети вы не знаете, достиг ли сервер предыдущего запроса, но ответ был потерян на полпути или первоначальный запрос вообще не достиг сервера. Если вы повторно отправите запрос, вы можете фактически создать дополнительный ресурс, поэтому POST не является идемпотентным. PUT с другой стороны имеет контракт, который заменяет текущее представление тем, которое содержится в запросе. Если вы отправляете один и тот же запрос дважды, содержимое ресурса должно быть одинаковым после обработки любого из двух PUT запросов. Обратите внимание, что фактический результат все еще может отличаться, поскольку служба может изменить полученный объект в соответствующее представление. Кроме того, между отправкой данных через PUT и их получением через GET еще один клиент мог обновить состояние между ними, поэтому нет гарантии, что вы действительно получите точное представление, которое вы отправили в службу.

Безопасность — еще одно обещание, которое поддерживают только GET, HEAD и OPTIONS. Он обещает инициатору, что он вообще не изменит какое-либо состояние, поэтому клиенты/посредники могут безопасно выдавать такой запрос, не опасаясь, что он изменит какое-либо состояние. На практике это важное обещание сканерам, которые вслепую обращаются к любым URL-адресам, чтобы изучить их содержимое. В случае нарушения таких обещаний, т. е. путем удаления данных при обработке GET запроса, виноват только разработчик сервиса, а не инициатор. Если сканер вызывает такие URL-адреса и, следовательно, удаляет некоторые данные, на самом деле это не ошибка сканеров, а только разработчик службы.

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

person Roman Vottner    schedule 21.03.2018