Какая конечная точка HTTP Verb for Read с телом запроса

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

Запрашивающая сторона может запросить либо полный набор данных, либо его подмножество. Подмножество определяется с помощью набора параметров, но параметры слишком длинные, чтобы вписаться в uri, максимальная длина которого составляет 2083 символа. https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=uri%20max%20length

Параметры можно легко отправить в теле запроса, но какой HTTP-глагол использовать правильно?

GET было бы идеально, но использование тела «не имеет семантического значения для запроса GET» HTTP GET с телом запроса

PUT не подходит, так как идентификатор отсутствует, а данные не обновляются и не заменяются.

POST не подходит, потому что новый ресурс не заменяется и, что более важно, сервер не генерирует и не генерирует идентификатор. http://www.restapitutorial.com/lessons/httpmethods.html

GET (чтение) кажется наиболее подходящим, но как мы можем включить сложный набор параметров для определения ответа?

Большое спасибо

Джон


http api rest endpoint httpverbs
person JHoward    schedule 07.12.2016    source источник

Ответы (3)


arrow_upward
1
arrow_downward

POST - правильный метод. POST следует использовать для любой операции, которая не стандартизирована HTTP, как в вашем случае, поскольку нет стандарта для операции GET с телом. Ссылка, которую вы связали, просто напрямую отображает методы HTTP в CRUD, что является анти-шаблоном REST.

person Pedro Werneck    schedule 04.08.2017

arrow_upward
0
arrow_downward

Вы правы, что GET с телом следует избегать. Вы можете поэкспериментировать с другими безопасными методами, которые принимают тело запроса (такими как REPORT или SEARCH), или вы действительно можете использовать POST. Я не вижу причин, почему последнее неверно; то, что вы цитируете, это просто мнение, а не спецификация.

person Julian Reschke    schedule 07.12.2016
comment
Спасибо за ваши комментарии Юлиана. w3.org/Protocols/rfc2616/rfc2616-sec9.html в риск начать разговор, я уверен, что ни у кого из нас нет времени на... 9.5 - нет субординации, поэтому POST кажется невозможным. 9.6 - вложенная запись не будет сохранена, так что PUT тоже кажется неуместным. Мне очень нравится концепция ОТЧЕТА, поэтому я буду исследовать это дальше - большое спасибо за указатель! - person JHoward; 07.12.2016
comment
RFC 2616 совершенно не имеет значения. См. greenbytes.de/tech/webdav/rfc7231.html#POST для текущая спецификация. - person Julian Reschke; 07.12.2016

arrow_upward
0
arrow_downward

Предполагая, что запросы к этому большому набору данных не являются полностью случайными, вам следует подумать о добавлении сохраненных запросов в свой API. Таким образом, клиенты могут добавлять, удалять, обновлять запросы (через тело запроса), используя POST DELETE PUT. Может быть, вы можете назвать их «отчетами».

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

Но только если не все запросы от клиентов уникальны.

person Szabolcs Heilig    schedule 07.12.2016
comment
Привет, Сабольч, решение действительно хранит некоторые запросы, и мы обслуживаем именно тот сценарий, который вы предложили (великие умы!), но в этом контексте запрос предназначен для подмножества данных, и запрашивающая сторона не может хранить свой запрос. Хотя, возможно, нам следует пересмотреть это. Спасибо за идею. - person JHoward; 07.12.2016