URLs RESTful pour la collecte d'objets

Question

J'ai une entité Temperature .

Mes URL sont conçues comme suit :

 GET     /api/temperatures/new
 GET     /api/temperatures/{id}/edit
 GET     /api/temperatures
POST     /api/temperatures
 PUT     /api/temperatures/{id}
DELETE   /api/monitoring/temperatures/{id}

Je voudrais créer plusieurs températures (une collection de températures) en une seule fois. Existe-t-il des conventions en termes d'url à utiliser ?

Jusqu'à présent, j'ai obtenu les résultats suivants :

POST /api/monitoring/temperatures/collection
GET  /api/monitoring/temperatures/cnew

J'ai pensé qu'il devait déjà exister une convention à ce sujet et j'aimerais vérifier avec vous.

Answer 1

GET     /api/temperatures  # Getting all resources
POST    /api/temperatures  # Create new resource
GET     /api/temperatures/<id>  # Get a single resource
PUT     /api/temperatures/<id>  # Edit all fields
PATCH   /api/temperatures/<id>  # Edit some fields
DELETE  /api/temperatures/<id>  # Delete a resource

Ce sont les types d'URL que Fielding décrit dans sa thèse sur REST. Vous ne devriez pas décrire ce que fait un point final dans l'URL, surtout lorsqu'il est utilisé correctement, les verbes HTTP fournissent beaucoup d'informations. Sachez que le style architectural REST ne se limite pas à JSON sur HTTP. Les connecteurs génériques, le découplage des composants et un serveur sans état sont des éléments clés d'une application RESTful.

Remarque : la plupart des gens ne mettront probablement pas en œuvre à la fois PUT et PATCH. PUT sera parfait, mais je l'ai inclus par souci d'exhaustivité.

En réponse à votre commentaire, si vous faites référence à la création de plusieurs ressources avec une seule requête POST, vous n'avez pas besoin d'une nouvelle URL. Votre application devrait être capable de gérer {temp: 45, date: ...} y [{temp: 45, date: ...}, {temp: 50, date: ...}] au même endroit.

Answer 2

La méthode HTTP GET ne convient pas pour créer ou modifier des ressources - /api/temperatures/new y /api/temperatures/{id}/edit . HTTP GET est utilisé pour obtenir des informations sans changer d'état dans un serveur. Vous devez utilice POST o PUT .

Si vous voulez créer plusieurs températures, vous devez utiliser

POST /api/monitoring/temperatures

et consommer des listes d'objets JSON ou XML.

Exemple de Java :

@POST
@Path("/temperatures")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Response postTemperatures(Temperatures temperatures){
    // process and save
}

@XmlRootElement
public class Temperatures {

    public List<Temperature> temperatures;

    Temperatures(){}
}

Answer 3

Vous pouvez mettre à jour plusieurs entrées avec un seul message en envoyant un tableau de températures au lieu d'une seule entrée,

POST     /api/temperatures  { [{...},{...}] } 

mais la structure de vos points d'accès pourrait être un peu simplifiée.

Idéalement, vous souhaitez une interface simple et cohérente pour toutes les ressources de l'API.

Je simplifierais personnellement :

 GET     /api/temperatures/new
 GET     /api/temperatures/{id}/edit
 GET     /api/temperatures
POST     /api/temperatures
 PUT     /api/temperatures/{id}
DELETE   /api/monitoring/temperatures/{id}

à

 GET     /api/temperatures            // Get all temperatures
POST     /api/temperatures            // Send in array of new entries to update
 GET     /api/temperatures/{id}       // Read a specific temperature
 PUT     /api/temperatures/{id}       // Update a specific temperature
DELETE   /api/temperatures/{id}       // Delete a specific temperature

Cela donne une interface cohérente à l'api pour tous les appels liés à la température qui correspondent à un fichier CRUD interface.

Sans contexte, il est difficile de savoir exactement à quoi sert /api/temperatures/new, mais j'envisagerais d'utiliser un paramètre sur l'appel pour affiner la réponse.

par exemple

/api/temperatures?age=new      // Get new temps

Ce qui vous permettra d'utiliser la structure commune pour ajouter ultérieurement différents types de critères.