Multiples remplacement de l'entité dans une interface RESTful

Question

J'ai un service avec certaines entités que je voudrais exposer d'une manière RESTful. En raison de certaines des exigences que j'ai du mal à trouver une façon que je trouve bien.

Ce sont les opérations « normales » je compte le soutien:

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 :)

Maintenant, les exigences supplémentaires:

• Nous devons être en mesure de remplacer l'ensemble des entités avec une toute nouvelle série d'entités (la fusion peut se produire en interne comme une optimisation).

  Je pensé à utiliser POST /rest/entity pour cela, mais cela supprimerait la possibilité de créer une entité unique et à moins que je propose que la fonctionnalité. Je l'ai vu / repos / entité / chemins nouveau style dans d'autres endroits, mais il semblait toujours un peu bizarre de réutiliser le segment de chemin identifiant pour que, comme il pourrait ou pourrait ne pas être une collision dans les ID (pas dans mon cas, mais le mélange comme namespaces qui me donne une démangeaison:)

  Y a-t-il des pratiques communes pour ce type d'opération? J'ai aussi considéré /rest/import/entity comme un chemin séparé pour les opérations non reposants similaires pour d'autres types d'entités que nous pourrions avoir, mais je ne aime pas le déplacer en dehors du chemin de la maison de l'entité.

• Nous devons être en mesure d'effectuer la plupart des opérations dans un -mode « à la gestion à sec » à des fins de validation.

  chaînes de requête sont généralement considérés comme anathème, mais je suis déjà un pécheur pour celui du filtre. Pour le mode de validation, serait l'ajout d'un drapeau ?validate ou ?dryrun ok? Avez quelqu'un fait quelque chose de semblable? Quels sont les inconvénients? Ceci est conçu comme une aide pour les interfaces utilisateur face à facilement mettre en œuvre la validation.

Nous ne prévoyons pas avoir à utiliser un mécanisme de mise en cache que c'est un service de configuration minuscule rarement touché, donc l'optimisation de la mise en cache est pas strictement nécessaire

Answer 1

  

Nous devons être en mesure de remplacer l'ensemble des entités avec un   toute nouvelle série de jeu entitiescompletely nouvelle des entités

C'est ce que cela ne, pas?

PUT /rest/entity

PUT doit remplacer la sémantique. Peut-être que vous pouvez utiliser le PATCH verbe support modifions partielles.

Personnellement, je changerais le nom de la ressource à « EntityList » ou « EntityCollection », mais c'est juste parce qu'il est plus clair pour moi.