2010-10-04 6 views
1

J'ai un service avec certaines entités que je souhaite exposer de manière RESTful. En raison de certaines des exigences, j'ai du mal à trouver un moyen que je trouve bien.Remplacement d'entités multiples dans une interface RESTful

Ce sont les opérations « normales » Je souhaite soutenir:

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 un ensemble d'entités complètement nouveau (la fusion peut se produire en interne en tant qu'optimisation).

    Je pensais utiliser POST /rest/entity pour cela, mais cela supprimerait la possibilité de créer des entités simples, sauf si je déplace cette fonctionnalité. J'ai vu/rest/entity/new-style chemins dans d'autres endroits, mais il semblait toujours un peu étrange de réutiliser le segment de chemin d'ID pour cela car il pourrait ou non y avoir une collision dans les ID (pas dans mon cas, mais mélanger des espaces de noms comme ça me donne une démangeaison :)

    Existe-t-il des pratiques courantes pour ce type d'opération? J'ai également considéré /rest/import/entity comme un chemin séparé pour des opérations non reposantes similaires pour d'autres types d'entités que nous pourrions avoir, mais je n'aime pas le déplacer en dehors du chemin d'origine de l'entité.

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

    Les chaînes de requête sont généralement considérées comme un anathème, mais je suis déjà un pécheur pour le filtre. Pour le mode de validation, est-ce que l'ajout d'un drapeau ?validate ou ?dryrun serait acceptable? Est-ce que quelqu'un a fait quelque chose de similaire? Quels sont les inconvénients? Ceci est conçu comme une aide pour les interfaces face à l'utilisateur pour implémenter la validation facilement.

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

Répondre

2

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

C'est ce que cela fait, non?

PUT /rest/entity 

PUT a la sémantique de remplacement. Peut-être pourriez-vous utiliser le verbe PATCH pour prendre en charge les mises à jour partielles. Personnellement, je changerais le nom de la ressource en "EntityList" ou "EntityCollection", mais c'est juste parce que c'est plus clair pour moi.

+0

Merci pour la réponse ... PATCH, dites-vous? Je vais aller le voir. –

+0

@Henrik https://datatracker.ietf.org/doc/rfc5789/ –

+0

Donc, PUT -> remplacer tout; PATCH -> remplacer certains. Tant que tout ce que nous avons l'intention d'utiliser peut utiliser PATCH, cela semble être le meilleur moyen. Merci! –