Я хочу получить данные о куче ресурсов. Скажем, Массив идентификатора книги, и ответом является JSON Массив объектов книги.
Если вы думаете о передаче массива идентификатора книги в качестве тела сообщения HTTP-запроса, то GET - это плохая идея .
Полезная нагрузка в сообщении запроса GET не имеет определенной семантики; отправка тела полезной нагрузки по запросу GET может привести к тому, что некоторые существующие реализации отклонят запрос.
Вы должны использовать вместо POST
POST, кажется, сбивает с толку, поскольку предполагается, что он будет использоваться только тогда, когда запрос создает ресурс или изменяет состояние сервера.
Это не совсем верно. POST может использоваться для чего угодно - см. GraphQL или SOAP . Но с помощью POST вы отказываетесь от способности промежуточных компонентов участвовать в беседе.
Например, для случаев, которые эффективно доступны только для чтения, вы хотели бы использовать безопасный метод, поскольку он позволяет оптимизировать предварительное кэширование и автоматически повторять потерянные ответы в ненадежной сети. POST не имеет дополнительных семантических ограничений, поэтому вы проигрываете.
HTTP действительно хочет, чтобы вы GET использовали URI; это можно сделать одним из двух относительно простых способов:
1) Разместите идентификаторы на сервере, чтобы создать новый ресурс (это означает, что сервер сохраняет для себя копию списка идентификаторов) и получить новый идентификатор ресурса в обмен. Затем получите этот новый идентификатор в любое время, когда захотите узнать текущее представление результатов.
2) Кодируйте необходимую информацию в сам URI. Чаще всего это делается с помощью части запроса URI, хотя это не является строго обязательным. Недостатком здесь является то, что если представление массива идентификаторов в кодировке URI очень длинное, у вас могут возникнуть проблемы с некоторыми реализациями, которые обеспечивают произвольные ограничения URI.
Не всегда хорошие ответы:
Интерфейс REST спроектирован так, чтобы быть эффективным для передачи крупномасштабных гипермедиа-данных, оптимизируя его для общего случая Интернета, но в результате получая интерфейс, который не оптимален для других форм архитектурного взаимодействия.