Comment est-il possible d'agir sur une ressource? C'est ce que nous allons voir dans cette vidéo. Il y a deux grands types d'opérations possibles. La plus courante s'appelle CRUD. Create, read, update, delete. Ce sont des opérations standards de type Restful qui permettent de manipuler une ressource, de la lire, de changer son état ou de l'effacer. Il y a des opérations spéciales, qui est une traduction de custom operation. Une opération spéciale peut être associée à une ressource et on a le format standard que nous avons vu pour l'URI, ou non associée à une ressource, mais plutôt à un service. Et on a un format très légèrement différent. Toutes les opérations sont implémentées avec des méthodes HTTP standard. En HTTP, on parle de méthodes plutôt que de commandes. Les méthodes sont PUT, POST, DELETE, GET et parfois PATCH. À toute requête correspond une réponse avec un code sous la forme d'un nombre à trois chiffres. Quand nous avons 200, 201 ou les suivants, il s'agit d'un succès. L'opération a été correctement effectuée. Quand il s'agit de 300, 307, 308 et les suivants, le serveur indique une redirection en général, un autre serveur. 307 et 308 correspondent à des redirections soit permanentes soit temporaires. Lorsqu'il y a une erreur du client, par exemple l'URI ne correspond à aucune ressource existante, nous avons une réponse de type 400, 401, ou les suivantes. C'est une erreur des clients. Lorsque par exemple, le serveur est surchargé ou qu'il y a un problème, qu'il ne peut pas traiter l'opération, à ce moment-là , une réponse de type 500 est envoyée. Voyons quelques exemples d'opérations. La plus simple, la lecture. Dans tout ce que nous voyons, nous supposons que la connexion TCP et éventuellement la connexion TLS sont déjà établies. Une lecture se fait avec une méthode HTTP GET. On a le nom de la méthode qui est dans le message en mode texte et ensuite l'URI de la ressource qu'on veut lire sans la partie API root. Ici, nous retrouvons un format que nous avons déjà étudié. L'UDM va lire ici il s'agit du profil d'abonné, il va lire le profil d'abonné et répondre avec un message 200 OK dans lequel il placera le profil d'abonné pour ce qui concerne les sessions PDU. Nous avons ici un exemple d'opération idempotente. Si plusieurs GET successifs sont faits avec le même URI, la réponse doit être la même. Voyons maintenant un exemple de création. La création se fait avec une méthode PUT ou POST. Considérons le cas d'un UE qui s'enregistre dans le réseau. Le fait que cet UE est joignable et qu'il est dans une certaine zone de suivi ou tracking area, est pris en charge par l'UDM avec le service de gestion de contexte. C'est donc une ressource dans l'UDM. L'URI de la ressource créée et envoyée dans la réponse est précisément dans l'en-tête HTTP location. L'URI a toujours le même format, nous ne revenons pas dessus. Et l'AMF pour créer la ressource fait un PUT, indique l'URI. L'UDM crée la ressource et la totalité de l'URI est renvoyée dans la réponse. Quelques cas d'erreurs possibles. Si le SUPI n'est pas connu, cela ne correspond pas à un abonné. À ce moment-là , l'UDM va renvoyer une réponse 404 Not Found. S'il y a des restrictions d'accès, le terminal n'a pas le droit d'accéder par exemple à cet AMF ou d'être dans la zone de suivi. Il va avoir une réponse 403 Forbidden. Un autre exemple de création, c'est l'établissement d'une session PDU. L'existence et les caractéristiques de la session correspondent à une ressource dans l'UDM toujours pour le même service de gestion de contexte. Le SMF au moment de la création va envoyer un PUT, va indiquer l'URI. Et ici, nous pouvons remarquer qu'il y a un champ supplémentaire qui donne un identificateur de session, car un même UE peut faire plusieurs sessions. La ressource est créée et encore une fois, la totalité de l'URI est indiquée dans la réponse. Lorsque l'UE arrête, termine la session PDU, la ressource doit être effacée. C'est une opération qui se fait avec une méthode DELETE. Toujours la même chose, l'URI est à chaque fois indiquée, la méthode DELETE. L'UDM efface la ressource et la ressource étant correctement effacée, on a une réponse positive de type 200. Voyons maintenant des exemples de mises à jour, d'updates. Cela se fait avec un PUT ou un POST, exemple, mobilité d'un UE. Un UE change d'AMF. Ici, on a une modification qui est considérée comme majeure de la ressource. Un PUT est envoyé avec l'URI de la ressource. La ressource est mise à jour et on renvoie un 204 No Content. Le cas du désenregistrement d'un UE n'est pas un effacement comme ce qu'on a vu pour la session, mais une mise à jour partielle. Parce qu'en fait, on veut garder l'information que l'UE est bien dans le réseau, existe toujours. Et cette mise à jour partielle correspond juste au positionnement d'un flag, comme quoi l'UE n'est plus accessible. Donc, on modifie juste un champ de la ressource. Et dans ce cas-là , c'est une méthode PATCH qui est employée. Voyons enfin un exemple d'opération spéciale ou custom operation. Considérons l'AUSF qui demande un vecteur d'authentification à l'UDM. À première vue, on pourrait se dire qu'on fait cela avec un GET. Eh bien non, parce que la ressource n'existe pas préalablement. C'est donc un POST qui est spécifié. On indique un URI spécifique au terminal avec le supi ou le suci, Il y a génération d'un vecteur d'authentification frais, qui est renvoyé dans la réponse 200 OK qui est une réponse positive. Ce n'est pas une opération CRUD et ce n'est pas idempotent. Pourquoi? Parce que si on envoie, si l'AUSF envoie une deuxième demande de vecteur, c'est évidemment un vecteur différent qui va être renvoyé. Clairement, il n'y a pas idempotence. L'ensemble des méthodes, l'ensemble des URI qui sont fournies par une NF est spécifié avec la méthodologie OpenAPI3.0 qui utilise le langage YAML. C'est un langage orienté texte. Sans rentrer dans les détails, en regardant cet exemple, nous pouvons voir qu'il y a le titre du service, Nudm_SDM, nous l'avons déjà vu. Une description Subscriber Data Management Service. L'URI qui est spécifiée avec notamment le nom de l'API ici. La version et toujours le champ API Root qui est disponible pour l'opérateur. La suite de l'URI est indiquée et ensuite, on va lister les méthodes, ici une méthode GET. Le nom de l'opération est indiqué, GetSMFSelData, et les différents paramètres qui peuvent être envoyés et qui quelques fois sont requis. La liste des réponses possibles est ensuite listée. Une réponse 200 positive ou une réponse 400 ou 404, ou les cas d'erreur 500, 503. Pour toutes les NF et tous les services, de telles spécifications sont disponibles sur le serveur 3GPP. Pour conclure, nous avons vu qu'une ressource peut être manipulée via des opérations CRUD principalement. Create, création avec une méthode HTTP PUT ou POST. Read, lecture avec une méthode HTTP GET. Update, une mise à jour avec une méthode HTTP PUT ou PATCH. Et un effacement avec HTTP DELETE. Dans tous les cas, la ressource sur laquelle on agit est indiquée par l'URI qui a donc un rôle fondamental. [MUSIQUE] [MUSIQUE]
