Замена нескольких объектов в интерфейсе RESTful - PullRequest
Новая
       1

Замена нескольких объектов в интерфейсе RESTful

1 голос
/ 04 октября 2010

У меня есть служба с некоторыми объектами, которую я хотел бы представить 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?Кто-нибудь делал что-нибудь подобное?Какие недостатки?Это делается для того, чтобы пользовательские интерфейсы могли легко реализовать проверку.

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

1 Ответ

2 голосов
/ 04 октября 2010

Нам нужно иметь возможность заменить весь набор сущностей на совершенно новый набор сущностей, совершенно новый набор сущностей

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

PUT /rest/entity

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

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

...