Множественная замена объекта в интерфейсе RESTful

Question

У меня есть служба с некоторыми объектами, которые я хотел бы открыть в RESTful способом. Из-за некоторых требований у меня есть некоторые проблемы с поиском пути, который я нахожу хорошим.

Эти «нормальные» операции я намерен поддерживать:

GET /rest/entity[?filter=<query>] # Return (matching) entities. The filter is optional and just a convenience for us CLI curl-users :) 

GET /rest/entity/<id> # Return specific entity 

POST /rest/entity # Creates one or more new entities 

PUT /rest/entity/<id> # Updates specific entity 

PUT /rest/entity # Updates many entities (json-dict or multipart. Haven't decided yet) 

DELETE /rest/entity/<id> # Deletes specific entity 

DELETE /rest/entity # Deletes all entities (dangerous but very useful to us :) 

Теперь дополнительные требования:

• Мы должны быть в состоянии заменить весь набор объектов с полностью новый набор объектов (объединение может происходить внутри как оптимизация).

  Я думал об использовании POST /rest/entity для этого, но это позволило бы удалить возможность создания отдельных объектов, если я не переведу эту функциональность. Я видел пути/rest/entity/new-style в других местах, но всегда было немного странно повторно использовать сегмент пути id для этого, поскольку там может быть или не быть столкновение в идентификаторах (не в моем случае, но смешивание пространств имен, подобных этому, дает мне зуд :)

  Существуют ли какие-либо общие методы для такого типа операций? Я также рассмотрел /rest/import/entity как отдельный путь для аналогичных невосстанавливаемых операций для других типов объектов, которые у нас могут быть, но мне не нравится перемещать его за пределы исходного пути объекта.

• Мы должны иметь возможность выполнять большинство операций в режиме «сухого хода» для проверки.

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

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

Answer 1

Мы должны быть в состоянии заменить весь набор объектов с совершенно новым набором entitiescompletely нового набора сущностей

Вот что это делает, нет?

PUT /rest/entity 

PUT заменил семантику. Возможно, вы можете использовать глагол PATCH для поддержки частичных обновлений.

Лично я бы изменил имя ресурса на «EntityList» или «EntityCollection», но это только потому, что для меня это яснее.