Я создаю веб-API, и у меня есть сценарий, когда пользователи захотят загружать кучу данных навалом, которые затем будут загружаться в базу данных в виде нескольких отдельных записей. Эти данные могут быть совершенно новыми и, следовательно, созданы, или данные могут уже существовать и, таким образом, обновляться. Определения для POST и PUT, похоже, ожидают работать только с одним фрагментом данных, а созданный код состояния отражает это при предоставлении местоположения.Как разрешить пользователю создавать/обновлять объемные данные и сохранять спокойствие?
У меня уже есть методы, которые позволяют создавать или обновлять один кусок данных. Должен ли я писать дополнительные методы для облегчения создания и обновления этих объемных данных или я должен ожидать, что пользователь сделает индивидуальные вызовы (возможно, сотни тысяч раз) для загрузки своих данных? Что я должен возвращать в отношении кодов состояния и других данных? Какие глаголы запроса должны определять эти массовые вызовы?
Параметры/тело вызова API - это то, что я уже выложил. Я наклонялся к ПУТ, так что это хорошо. Но настоящие (жесткие) вопросы, которые я должен соблюдать, это: 1) это хорошая идея или ее следует избегать? 2) что должно быть возвращено пользователю? Нормально? Должен ли быть создан, если что-то было вставлено или были сделаны только вставки? Каким должен быть контент? Есть ли что-то еще, о чем я не думал? – Ellesedil
Одна проблема с не возвращением содержимого из этого запроса: если он создает новые элементы коллекции, вы не будете знать их идентификаторы. Поэтому, если вам нужны эти идентификаторы, [RFC2616] (https://www.ietf.org/rfc/rfc2616.txt) явно запрещает возвращать контент из PUT. – astreltsov
Я считаю, что ваш комментарий/редактировать неправильно. PUT, стр. 54: «Если новый ресурс создан, исходный сервер ДОЛЖЕН информировать пользовательский агент через ответ 201 (создан)». – Ellesedil