Format de données et codes HTTP

Les données de réponse d’entrée et de sortie pour les appels d’API peuvent être affichées au format JSON. JSON (JavaScript Object Notation) est un format d’échange de données léger. Pour récupérer la réponse au format JSON, ajoutez l’en-tête de demande Accept avec la valeur application/json.
cad140fr
Format de réponse de données
Les données de réponse d’entrée et de sortie pour les appels d’API peuvent être affichées au format JSON. JSON (JavaScript Object Notation) est un format d’échange de données léger. Pour récupérer la réponse au format JSON, ajoutez l’en-tête de demande Accept avec la valeur application/json.
Exemple d’éléments prédéfinis au format JSON :
[{"item_id":"1","product_id":"1","stock_id":"1","qty":"99.0000","low_stock_date":null},{"item_id":"2","product_id":"2","stock_id":"1","qty":"100.0000","low_stock_date":null}]
Codes de réponse HTTP
Les normes SCIM utilisent des codes de réponse HTTP pour indiquer la réussite ou l’échec des opérations. Les codes de statut HTTP appropriés décrivant l’erreur et le corps du message sont renvoyés pour toutes les demandes au format JSON.
Les réponses aux erreurs sont identifiées à l’aide de l’URI de schéma suivant : urn:ietf:params:scim:api:messages:2.0:Error.
Le tableau suivant contient les codes de statut HTTP communs possibles.
Codes de statut HTTP
Description
200 (Ok)
Indique la réussite de l'opération
201 (Created)
Utilisé lorsqu’une ressource a été créée à l’aide d'une demande POST ou PUT. Renvoie un lien vers la ressource nouvellement créée à l’aide de l’en-tête d’emplacement.
307 (Temporary Redirect)
Utilisé lorsqu'il est demandé au client de répéter la même demande HTTP à l’emplacement identifié. Le client ne doit pas utiliser l’emplacement dans la réponse comme référence permanente à la ressource et doit continuer à utiliser l'URI de demande d’origine.
308 (Permanent Redirect)
Utilisé lorsqu'il est indiqué au client de répéter la même demande HTTP à l’emplacement identifié. Le client doit utiliser l’emplacement dans la réponse comme référence permanente à la ressource.
204 (No Content)
Utilisé lorsque le corps de la réponse est vide. Par exemple, pour une demande DELETE.
400 (Bad Request)
Indique qu'une entrée non valide est spécifiée. Par exemple, pour une erreur de validation ou pour des données manquantes. Pour les types d’erreur SCIM, reportez-vous à la demande RFC 7644.
401 (Unauthorized)
Indique que l'utilisateur utilise un jeton d’authentification non valide ou incorrect.
403 (Forbidden)
Indique que l’utilisateur n’a pas accès à la méthode utilisée. Par exemple, pour la suppression des accès sans droits d’administrateur.
404 (Not Found)
Indique que la méthode n’est pas disponible.
409 (Conflict)
Indique qu'un conflit existe lors de l’exécution de la méthode. Par exemple, en cas d'ajout d’entrée en double.
412 (precondition Failed)
Echec de la mise à jour. La ressource a été modifiée sur le serveur.
500 (Internal Server Error)
Indique que le serveur a renvoyé une exception lors de l’exécution de la méthode.
501 (Not Implemented)
L’opération demandée n’est pas prise en charge par le fournisseur de services.
Exemple d’une erreur en réponse à une demande GET inexistante, affichée au format JSON :
HTTP/1.1 404 Not Found
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"detail":"Resource 2819c223-7f76-453a-919d-413861904646 not found",
"status": "404"
}
Exemple d’une erreur en réponse à une demande PUT :
HTTP/1.1 400 Bad Request
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:Error"],
"scimType":"mutability"
"detail":"Attribute 'id' is readOnly",
"status": "400"
}