Все примеры, которые я видел относительно архитектуры RESTful, касались одной записи. Например, запрос GET на mydomain.com/foo/53, чтобы получить foo 53 или POST до mydomain.com/foo, чтобы создать новый Foo.
Но как насчет нескольких записей? Возможность запросить серию Foos по id или опубликовать массив новых Foos, как правило, будет более эффективным с помощью одного запроса API, а не десятка отдельных запросов. Вы перегрузили бы mydomain.com/foo для обработки запросов как для одной, так и для нескольких записей? Или вы добавили бы mydomain.com/foo-multiple для обработки множественных POST и GET?
Я разрабатываю систему, которая потенциально может потребовать получить сразу несколько записей (что-то похожее на mydomain.com/foo/53,54,66,86,87). Но так как я не видел никаких примеров этого, мне интересно, есть ли что-то, что я просто не получая архитектуру RESTful, которая делает этот подход "неправильным".
В то время как я не вижу ничего неправильного в вашем подходе, кажется немного странным, если пользователь вашего API хочет иметь записи foo с произвольными идентификаторами. Я сразу же подозреваю, что они используют идентификаторы для представления другой концепции, например, всех foo, которые были созданы на прошлой неделе, и т.д. Если это то, что они делают, тогда вы, вероятно, должны вместо использования списка идентификаторов в качестве суррогата.
Существует хорошая причина не возвращать несколько записей в одном запросе, она менее кэшируема и менее масштабируема. В любое время, когда вы задаетесь вопросом, как и почему REST предполагается работать, посмотрите веб-страницу. Когда вы запрашиваете страницу, она сводится к ссылкам на другие ресурсы, такие как несколько изображений, css файлы, js файлы и т.д.
В то время как может показаться более эффективным попробовать и перекачать все эти данные по одному запросу, он будет гораздо более масштабируемым и кэшируемым, чтобы обрабатывать их все как отдельные ресурсы и позволить веб-серверу и подключению к сети поддерживать связь с запрос многих ресурсов эффективен. Если вы включили все эти css, javascript и изображения в какую-то одну загрузку, которая могла бы представлять всю страницу, когда вы посещаете другую страницу, на которой нужны одни и те же ресурсы, вы должны загрузить их все снова, потому что вы не ссылались на них должным образом как отдельный ресурс в первый раз, когда браузер может кэшировать.
Когда у вас есть что-то, что представляет собой список из нескольких ресурсов, спокойный способ сделать это состоит в том, чтобы список был ничем иным, как списком URL-адресов для отдельных ресурсов и извлекать каждый из них отдельно, как говорят веб-страницы в мерцании содержат URL-адреса для всех изображений на странице, они не пытаются и встроить их все в саму страницу.
Когда ресурсы должным образом разрешают кэширование и на которые ссылаются индивидуально, скорость попадания в кеш может быть абсурдно высокой, позволяя веб-серверу обрабатывать гораздо большую нагрузку и позволяя кэшировать прокси-серверы между клиентом и сервером, чтобы предотвратить запрос даже от удара сервер. Веб работает хорошо, используя этот подход, прежде чем думать, что это кажется сумасшедшим, подумайте об этом.
Это старый вопрос, но, тем не менее, я пишу это для всех, кто может приземлиться здесь, ища ответ.
Существует множество веских причин, по которым приложение запрашивает несколько записей, указанных в ID, и нет, не должно быть никакой логики, например, "созданной на прошлой неделе" или "созданной между Date1 и Date2" и т.д. Представьте ситуацию где пользователю предоставляется сетка/список записей, и они могут вручную выбрать несколько записей для дальнейшей обработки.
Таким образом, многие решения уже предлагаются здесь: Как создать REST API, который принимает массив идентификаторов для ресурсов
Тем не менее, IMHO лучшим решением является одно из @nilesh в том же обсуждении: fooobar.com/info/76135/...
Сначала выполните POST, передавая идентификаторы, которые вы хотите получить, сервер вернет идентификатор пакета, а затем вы получите GET с этим идентификатором партии, чтобы получить все записи.