Vladimir, développeur web chez Noveo, déclare :
La plupart des développeurs de sites Web, de services Web et d'applications mobiles doivent tôt ou tard s'occuper de l'architecture client-serveur, à savoir développer une API Web ou s'y intégrer. Afin de ne pas inventer quelque chose de nouveau à chaque fois, il est important de développer une approche relativement universelle de la conception d'API web, basée sur l'expérience de développement. systèmes similaires. Nous attirons votre attention sur une série combinée d'articles consacrés à cette question.
Première approximation : personnages
À un moment donné, en train de créer un autre service Web, j'ai décidé de rassembler toutes mes connaissances et réflexions sur le thème de la conception d'une API Web pour répondre aux besoins des applications clientes et de la présenter sous la forme d'un article ou d'une série de des articles. Bien entendu, mon expérience n’est pas absolue et les critiques et ajouts constructifs sont plus que bienvenus.
La lecture s'est avérée plus philosophique que technique, mais pour les fans de la partie technique, il y aura de quoi réfléchir. Je doute que je dirai dans cet article quelque chose de fondamentalement nouveau, quelque chose dont vous n'avez jamais entendu parler, lu ou pensé vous-même. J'essaie juste de tout intégrer système unifié, d'abord dans votre propre tête, et cela vaut déjà beaucoup. Néanmoins, je serai heureux si mes pensées vous seront utiles dans votre pratique. Alors allons-y.
Client et serveur
Serveur dans ce cas, nous considérons une machine abstraite sur le réseau capable de recevoir une requête HTTP, de la traiter et de renvoyer la réponse correcte. Dans le contexte de cet article, son essence physique et son architecture interne n'ont absolument aucune importance, qu'il s'agisse d'un ordinateur portable d'étudiant ou d'un énorme cluster de serveurs industriels dispersés dans le monde. De la même manière, peu importe ce qu'il y a sous le capot, qui accueille la requête à la porte, Apache ou Nginx, quelle bête inconnue, PHP, Python ou Ruby la traite et génère une réponse, quel stockage de données est utilisé : Postgresql, MySQL ou MongoDB . L'essentiel est que le serveur respecte la règle principale : entendre, comprendre et pardonner.
Client il peut également s'agir de tout ce qui est capable de générer et d'envoyer une requête HTTP. Jusqu'à un certain point dans cet article, nous ne nous intéresserons pas non plus particulièrement aux objectifs que le client se fixe lors de l'envoi de cette demande, ni à ce qu'il fera de la réponse. Le client peut être un script JavaScript exécuté dans le navigateur, application mobile, un démon maléfique (ou pas si maléfique) fonctionnant sur le serveur, ou un réfrigérateur trop sage (il existe déjà de telles choses).
Pour l'essentiel, nous parlerons de la méthode de communication entre les deux ci-dessus, de manière à ce qu'ils se comprennent, et qu'aucun d'eux n'ait de questions.
Philosophie REST
REST (Representational State Transfer) a été conçu à l'origine comme une interface simple et sans ambiguïté pour la gestion des données, ne nécessitant que quelques opérations de base avec direct stockage réseau(par le serveur) : récupération des données (GET), sauvegarde (POST), modification (PUT/PATCH) et suppression (DELETE). Bien entendu, cette liste était toujours accompagnée d'options telles que la gestion des erreurs dans la requête (la requête est-elle compilée correctement), la restriction de l'accès aux données (du coup, vous ne devriez pas le savoir) et la validation des données entrantes (du coup vous avez écrit des bêtises), en en général, toutes les vérifications possibles, que le serveur exécute avant de répondre au souhait client.
De plus, REST comporte un certain nombre de principes architecturaux, dont une liste peut être trouvée dans tout autre article sur REST. Passons-les brièvement en revue pour qu'ils soient à portée de main et que vous n'ayez à vous déplacer nulle part :
Indépendance du serveur par rapport au client- les serveurs et les clients peuvent être instantanément remplacés par d'autres indépendamment les uns des autres, puisque l'interface entre eux ne change pas. Le serveur ne stocke pas les états des clients.
Unicité des adresses de ressources- chaque unité de données (quel que soit le degré d'imbrication) a sa propre URL unique, qui, en fait, est entièrement un identifiant de ressource unique.
Exemple: OBTENIR /api/v1/users/25/nom
Indépendance du format de stockage des données par rapport au format de transmission- le serveur peut en supporter plusieurs divers formats pour transférer les mêmes données (JSON, XML, etc.), mais stocke les données dans son format interne, quels que soient ceux pris en charge.
Présence de toutes les métadonnées nécessaires dans la réponse- en plus des données elles-mêmes, le serveur doit renvoyer les détails du traitement de la demande, par exemple des messages d'erreur, diverses propriétés de la ressource nécessaires à un travail ultérieur avec elle, par exemple le nombre total d'enregistrements de la collection pour un affichage correct de navigation dans les pages. Nous reviendrons plus tard sur les différents types de ressources.
Que nous manque-t-il ?
Le REST classique implique que le client travaille avec le serveur comme un magasin de données plat, alors que rien n'est dit sur la connectivité et l'interdépendance des données entre elles. Tout cela, par défaut, repose entièrement sur les épaules de l'application cliente. Cependant, moderne domaines, pour lesquels des systèmes de gestion de données sont développés, qu'il s'agisse de services sociaux ou de systèmes de marketing en ligne, impliquent une relation complexe entre les entités stockées dans la base de données. Soutenir ces connexions, c'est-à-dire l'intégrité des données relève de la responsabilité du côté serveur, tandis que le client n'est qu'une interface pour accéder à ces données. Alors, qu’est-ce qui nous manque dans REST ?
Appels de fonction
Afin de ne pas modifier manuellement les données et les connexions entre elles, nous appelons simplement une fonction sur la ressource et lui « transmettons » les données nécessaires comme argument. Cette opération ne correspond pas aux standards REST, il n'y a pas de verbe spécial pour cela, ce qui nous oblige, nous développeurs, à sortir de notre chemin.
L'exemple le plus simple– autorisation de l'utilisateur. Nous appelons la fonction de connexion, lui transmettons un objet contenant les informations d'identification comme argument et recevons une clé d'accès en réponse. Nous ne nous soucions pas de ce qui arrive aux données côté serveur.
Une autre option– créer et rompre les connexions entre les données. Par exemple, ajouter un utilisateur à un groupe. Appeler l'entité groupe Fonction addUser, passant un objet en paramètre utilisateur, on obtient le résultat.
Et aussi Il existe des opérations qui ne sont pas directement liées au stockage des données en tant que telles, par exemple l'envoi de notifications, la confirmation ou le rejet d'éventuelles opérations (fin de la période de reporting, etc.).
Opérations multiples
Cela arrive souvent, et les développeurs clients comprendront ce que je veux dire, qu'il est plus pratique pour une application client de créer/modifier/supprimer/plusieurs objets homogènes à la fois avec une seule requête, et pour chaque objet, un verdict différent côté serveur est possible. . Il existe ici au moins plusieurs options : soit toutes les modifications ont été effectuées, soit elles ont été partiellement réalisées (pour certains objets), soit une erreur s'est produite. Eh bien, il existe également plusieurs stratégies : appliquer les modifications uniquement si tout le monde réussit, ou appliquer partiellement, ou revenir en arrière en cas d'erreur, et cela conduit déjà à un mécanisme de transaction à part entière.
Pour une API Web en quête d'idéalité, j'aimerais également intégrer d'une manière ou d'une autre de telles opérations dans le système. Je vais essayer de faire ça dans l'une des suites.
Requêtes statistiques, agrégateurs, formatage des données
Il arrive souvent qu'à partir des données stockées sur le serveur, nous ayons besoin d'obtenir une synthèse statistique ou des données formatées d'une manière particulière : par exemple, pour construire un graphique côté client. Il s’agit essentiellement de données générées à la demande, plus ou moins à la volée, et en lecture seule. Il est donc logique de les classer dans une catégorie à part. L’une des particularités des données statistiques, à mon avis, est qu’elles ne possèdent pas d’identifiant unique.
Je suis sûr que ce n'est pas tout ce que l'on peut rencontrer lors du développement d'applications réelles, et je serai heureux de voir vos ajouts et ajustements.
Types de données
Objets
Le type de données clé dans la communication entre le client et le serveur est un objet. Essentiellement, un objet est une liste de propriétés et leurs valeurs correspondantes. Nous pouvons envoyer un objet au serveur dans une requête et recevoir le résultat de la requête en tant qu'objet. Cependant, l'objet ne sera pas nécessairement l'entité réelle stockée dans la base de données, du moins pas sous la forme sous laquelle il a été envoyé ou reçu. Par exemple, les informations d'identification d'autorisation sont transmises en tant qu'objet, mais ne constituent pas une entité indépendante. Même les objets stockés dans la base de données ont tendance à devenir envahis par la végétation propriétés supplémentaires de nature intra-système, par exemple, les dates de création et d'édition, diverses étiquettes et indicateurs du système. Les propriétés des objets peuvent être soit leurs propres valeurs scalaires, soit contenir objets associés Et collections d'objets, qui ne font pas partie de l'objet. Certaines propriétés d'objet peuvent être modifiables, d'autres sont des propriétés système, en lecture seule, et certaines peuvent être de nature statistique et calculées à la volée (par exemple, le nombre de likes). Certaines propriétés des objets peuvent être masquées, en fonction des droits de l'utilisateur.
Collections d'objets
Lorsque nous parlons de collections, nous entendons un type de ressource serveur qui permet de travailler avec une liste d'objets homogènes, c'est-à-dire ajoutez, supprimez, modifiez des objets et sélectionnez-les. De plus, une collection pourrait théoriquement avoir ses propres propriétés (par exemple, le nombre maximum d'éléments par page) et fonctions (je suis confus ici, mais cela s'est également produit).
Valeurs scalaires
Dans leur forme pure, les valeurs scalaires en tant qu'entité distincte sont extrêmement rares dans ma mémoire. Généralement, ils apparaissent comme propriétés d’objets ou de collections et, en tant que tels, ils peuvent être lus ou écrits. Par exemple, le nom d'utilisateur peut être récupéré et modifié individuellement avec GET /users/1/name . En pratique, cette fonctionnalité est rarement utile, mais si nécessaire, j'aimerais l'avoir à portée de main. Cela est particulièrement vrai pour les propriétés de collection, telles que le nombre d'enregistrements (avec ou sans filtrage) : GET /news/count .
Dans l'un des articles suivants, je vais essayer de classer ces opérations et de proposer des options pour d'éventuelles demandes et réponses, en fonction de celles que j'ai rencontrées dans la pratique.
Deuxième approximation : le bon chemin
Dans cette approche, je voudrais parler séparément des approches permettant de créer des chemins uniques vers les ressources et les méthodes de votre API Web et des fonctionnalités architecturales de l'application qui affectent l'apparence de ce chemin et de ses composants.
À quoi penser en se tenant sur le rivage
Gestion des versions
Tôt ou tard, tout système d'exploitation commence à évoluer : se développer, devenir plus complexe, évoluer et devenir plus moderne. Pour les développeurs d'API REST, cela se heurte avant tout à la nécessité de lancer de nouvelles versions de l'API pendant que les anciennes sont en cours d'exécution. Ici, je ne parle plus de changements architecturaux sous le capot de votre système, mais du fait que le format des données lui-même et l'ensemble des opérations qui l'accompagnent changent. Dans tous les cas, le versioning doit être prévu aussi bien dans l’organisation initiale du code source que dans le principe de construction des URL. En ce qui concerne les URL, il existe deux manières les plus courantes d'indiquer la version de l'API à laquelle la demande est adressée. Préfixer le chemin example-api.com/v1/ et séparer les versions au niveau du sous-domaine v1.example-api.com. Vous pouvez utiliser n’importe lequel d’entre eux, en fonction de vos besoins et exigences.
Autonomie des composants
L'API Web des systèmes complexes prenant en charge plusieurs rôles d'utilisateur nécessite souvent une division en parties, chacune remplissant sa propre gamme de tâches. En fait, chaque partie peut être une application indépendante, fonctionnant sur différents machines physiques et les plateformes. Dans le contexte de la description de l'API, la manière dont le serveur traite la demande et quelles forces et technologies sont impliquées dans cela n'a aucune importance pour nous. Pour le client, l'API est un système encapsulé. Cependant, différentes parties du système peuvent avoir des fonctionnalités complètement différentes, par exemple les parties administrative et utilisateur. Et la méthodologie pour travailler avec des ressources apparemment identiques peut différer considérablement. Par conséquent, ces parties doivent être séparées au niveau du domaine admin.v1.example-api.com ou du préfixe de chemin example-api.com/v1/admin/. Cette exigence n’est pas obligatoire et dépend en grande partie de la complexité du système et de son objectif.
Format d'échange de données
Le format d'échange de données le plus pratique et le plus fonctionnel, à mon avis, est JSON, mais personne n'interdit l'utilisation de XML, YAML ou tout autre format permettant de stocker des objets sérialisés sans perdre le type de données. Si vous le souhaitez, vous pouvez faire en sorte que l'API prenne en charge plusieurs formats d'entrée/sortie. Il suffit d'utiliser l'en-tête de requête HTTP pour indiquer le format de réponse Accept souhaité et Content-Type pour indiquer le format des données transmises dans la requête. Une autre méthode populaire consiste à ajouter une extension à l'URL de la ressource, par exemple GET /users.xml, mais cette méthode semble moins flexible et moins esthétique, ne serait-ce que parce qu'elle alourdit l'URL et est vraie pour les requêtes GET plutôt que pour toutes les requêtes possibles. opérations.
Localisation et multilinguisme
En pratique, la multilinguisation des API se résume le plus souvent à traduire les messages de service et d’erreur dans la langue requise pour un affichage direct à l’utilisateur final. Les contenus multilingues ont également leur place, mais le stockage et la diffusion de contenus sur différentes langues, à mon avis, devrait être différencié plus clairement, par exemple, si vous avez le même article dans différentes langues, il s'agit en fait de deux entités différentes, regroupées en fonction de l'unité du contenu. Pour identifier la langue attendue que vous pouvez utiliser différentes façons. Le plus simple est l'en-tête HTTP standard Accept-Language. J'ai vu d'autres moyens, comme l'ajout d'un paramètre GET language="en" , en utilisant le préfixe de chemin example-api.com/en/ , ou même au niveau du nom de domaine en.example-api.com . Il me semble que le choix de la manière de spécifier les paramètres régionaux dépend de l'application spécifique et des tâches auxquelles elle est confrontée.
Routage interne
Nous avons donc atteint le nœud racine de notre API (ou l'un de ses composants). Tous les autres itinéraires auront lieu directement dans votre application serveur, conformément à l'ensemble des ressources qu'elle prend en charge.
Chemins de collecte
Pour spécifier le chemin d'accès à la collection, on utilise simplement le nom de l'entité correspondante, par exemple, s'il s'agit d'une liste d'utilisateurs, alors le chemin sera /users. Deux méthodes sont applicables à la collection en tant que telle : GET (réception d'une liste limitée d'entités) et POST (création d'un nouvel élément). Dans les requêtes de listes, nous pouvons utiliser de nombreux paramètres GET supplémentaires utilisés pour la pagination, le tri, le filtrage, la recherche, etc., mais ils doivent être facultatifs, c'est-à-dire ces paramètres ne doivent pas être transmis dans le cadre du chemin !
Éléments de collection
Pour accéder à un élément de collection spécifique, nous utilisons son identifiant unique /users/25 dans le parcours. C’est le chemin unique qui y mène. Pour travailler avec un objet, les méthodes GET (obtention d'un objet), PUT/PATCH (modification) et DELETE (suppression) sont applicables.
Objets uniques
De nombreux services ont des objets uniques à l'utilisateur actuel, tels que le profil /profile de l'utilisateur actuel ou les paramètres personnels /settings . Bien sûr, d'une part, il s'agit d'éléments d'une des collections, mais ils sont le point de départ de l'utilisation de notre API Web par l'application client, et permettent également une gamme beaucoup plus large d'opérations sur les données. Dans ce cas, la collection stockant les paramètres des utilisateurs peut être totalement inaccessible pour des raisons de sécurité et de confidentialité des données.
Propriétés des objets et des collections
Pour accéder directement à l'une des propriétés d'un objet, il suffit d'ajouter le nom de la propriété au chemin d'accès à l'objet, par exemple, obtenez le nom d'utilisateur /users/25/name . Les méthodes GET (obtention d'une valeur) et PUT/PATCH (modification d'une valeur) sont applicables à une propriété. La méthode DELETE n'est pas applicable car une propriété est une partie structurelle d’un objet, en tant qu’unité de données formalisée.
Dans la partie précédente, nous avons évoqué le fait que les collections, comme les objets, peuvent avoir leurs propres propriétés. D'après mon expérience, la seule propriété que j'ai trouvée utile est la propriété count, mais votre application peut être plus complexe et spécifique. Les chemins vers les propriétés des collections sont construits selon le même principe que les propriétés de leurs éléments : /users/count . Applicable uniquement aux propriétés de collection Méthode OBTENIR(obtenir une propriété), parce que une collection n'est qu'une interface pour accéder à une liste.
Collections d'objets associés
Un type de propriété d'objet peut être constitué d'objets associés ou de collections d'objets associés. En règle générale, ces entités ne constituent pas la propriété propre d’un objet, mais seulement des références à ses connexions avec d’autres entités. Par exemple, une liste de rôles attribués à l'utilisateur /users/25/roles. Nous parlerons en détail du travail avec des objets et des collections imbriqués dans l'une des parties suivantes, mais à ce stade, il nous suffit d'avoir la possibilité d'y accéder directement, comme toute autre propriété d'un objet.
Fonctions des objets et des collections
Pour construire le chemin vers l'interface d'appel de fonction d'une collection ou d'un objet, nous utilisons la même approche que pour accéder à une propriété. Par exemple, pour l'objet /users/25/sendPasswordReminder ou la collection /users/disableUnconfirmed. Pour les appels de fonction, nous utilisons toujours la méthode POST. Pourquoi? Permettez-moi de vous rappeler que dans REST classique, il n'y a pas de verbe spécial pour appeler des fonctions, et nous devrons donc utiliser l'un de ceux existants. À mon avis, la méthode POST est la plus adaptée pour cela car... il vous permet de transmettre les arguments nécessaires au serveur, n'est pas idempotent (renvoyant le même résultat en cas d'accès multiple) et est le plus abstrait en termes de sémantique.
J'espère que tout rentre plus ou moins dans le système :) Dans la partie suivante, nous parlerons plus en détail des requêtes et réponses, de leurs formats et des codes d'état.
Troisième approximation : requêtes et réponses
Dans les approximations précédentes, j'ai expliqué comment est née l'idée de collecter et de résumer l'expérience existante. développement web API. Dans la première partie, j'ai essayé de décrire les types de ressources et d'opérations sur celles-ci que nous traitons lors de la conception d'une API Web. La deuxième partie a abordé la problématique de la construction d'URL uniques pour accéder à ces ressources. Et dans cette approximation, je vais essayer de décrire les options possibles pour les demandes et les réponses.
Réponse universelle
Nous avons déjà dit que le format spécifique de communication entre le serveur et le client peut être quelconque, à la discrétion du développeur. Pour moi, le format JSON semble être le plus pratique et le plus visuel, même si application réelle la prise en charge de plusieurs formats peut être implémentée. Concentrons-nous maintenant sur la structure et les attributs nécessaires de l'objet de réponse. Oui, nous envelopperons toutes les données renvoyées par le serveur dans un conteneur spécial - objet de réponse générique, qui contiendra tout le nécessaire des informations de service pour son traitement ultérieur. Alors, quelle est cette information :
Succès - marqueur du succès de la demande
Afin de comprendre immédiatement lors de la réception d'une réponse du serveur si la demande a réussi et de la transmettre au gestionnaire approprié, il suffit d'utiliser le jeton de réussite « succès ». La réponse du serveur la plus simple, ne contenant aucune donnée, ressemblerait à ceci :
POST /api/v1/articles/22/publish ("succès" : vrai)
Erreur - détails de l'erreur
Si la requête échoue - nous parlerons un peu plus tard des raisons et des types de réponses négatives du serveur - l'attribut « erreur » est ajouté à la réponse, contenant le code d'état HTTP et le texte du message d'erreur. Veuillez ne pas confondre avec les messages concernant erreurs de validation données pour des champs spécifiques. Il est plus correct, à mon avis, de renvoyer le code d'état dans l'en-tête de la réponse, mais j'ai également vu une autre approche : toujours renvoyer le statut 200 (succès) dans l'en-tête et envoyer les détails et les données d'erreur possibles dans le corps du réponse.
GET /api/v1/user ("succès": false, "erreur": ("code": 401, "message": "Échec de l'autorisation"))
Données - données renvoyées par le serveur
La plupart des réponses du serveur sont conçues pour renvoyer des données. Selon le type de demande et son succès, l'ensemble de données attendu variera, cependant, l'attribut « data » sera présent dans la grande majorité des réponses.
Exemple de données renvoyées en cas de succès. Dans ce cas, la réponse contient l'objet utilisateur demandé.
GET /api/v1/user ("succès": true, "data": ( "id": 125, "email": " [email protégé]", "nom" : "John", "nom" : "Smith", ) )
Un exemple des données renvoyées en cas d'erreur. Dans ce cas, il contient les noms de champs et les messages d'erreur de validation.
PUT /api/v1/user ( "success": false, "error": ( "code" : 422, "message" : "Validation failed" ) "data": ( "email" : "L'e-mail ne peut pas être vide. ", ) )
Pagination - informations nécessaires pour organiser la navigation dans les pages
En plus des données elles-mêmes, dans les réponses renvoyant ensemble d'éléments de collection, les informations sur la navigation dans les pages (pagination) basées sur les résultats de la requête doivent être présentes.
L'ensemble minimum de valeurs pour la pagination comprend :
- nombre total d'enregistrements ;
- nombre de pages;
- numéros de page actuels ;
- nombre d'enregistrements par page ;
- le nombre maximum d'enregistrements par page pris en charge par le côté serveur.
Quelques développeurs web Les API incluent également dans la pagination un ensemble de liens prêts à l'emploi vers des pages adjacentes, ainsi que la première, la dernière et l'actuelle.
GET /api/v1/articles Réponse : ( "success": true, "data": [ ( "id" : 1, "title" : "Chose intéressante", ), ( "id" : 2, "title" : "Texte ennuyeux", ) ], "pagination": ( "totalRecords" : 2, "totalPages" : 1, "currentPage" : 1, "perPage" : 20, "maxPerPage" : 100, ) )
Travailler sur les erreurs
Comme mentionné ci-dessus, toutes les requêtes adressées à l’API web n’aboutissent pas, mais cela fait aussi partie du jeu. Un système de rapport d'erreurs est un outil puissant qui facilite le travail du client et guide l'application client sur la bonne voie. Le mot « erreur » dans ce contexte n’est pas tout à fait approprié. Un meilleur mot ici serait exception, puisqu'en fait la demande a été reçue, analysée et une réponse adéquate a été renvoyée expliquant pourquoi la demande n'a pas pu être complétée.
Quelles sont les raisons potentielles des exceptions que vous recevez ?
500 Erreur interne du serveur - tout est cassé, mais nous le réparerons bientôt
C'est exactement le cas lorsque le problème s'est produit du côté du serveur lui-même, et que l'application cliente ne peut que soupirer et informer l'utilisateur que le serveur est fatigué et se couche pour se reposer. Par exemple, la connexion à la base de données est perdue ou il y a un bug dans le code.
400 Mauvaise demande - et maintenant tout est cassé pour vous
La réponse est exactement le contraire de la précédente. Renvoyé dans les cas où l'application client envoie une requête qui, en principe, ne peut pas être traitée correctement, ne contient pas les paramètres requis ou a erreurs de syntaxe. Ce problème peut généralement être résolu en relisant la documentation de l'API Web.
401 Non autorisé - étranger, identifiez-vous
Une autorisation est requise pour accéder à cette ressource. Bien sûr, avoir une autorisation ne garantit pas que la ressource sera disponible, mais sans autorisation, vous ne le saurez certainement pas. Se produit, par exemple, lors d'une tentative d'accès à une partie privée de l'API ou lorsque le token actuel a expiré.
403 Interdit - vous n'êtes pas autorisé ici
La ressource demandée existe, mais l'utilisateur ne dispose pas des droits suffisants pour la visualiser ou la modifier.
404 Non trouvé - personne n'habite à cette adresse
Une telle réponse est renvoyée, en règle générale, dans trois cas : le chemin d'accès à la ressource est incorrect (erroné), la ressource demandée a été supprimée et a cessé d'exister, les droits de l'utilisateur actuel ne lui permettent pas de connaître l'existence de la ressource demandée. Par exemple, alors que nous parcourions une liste de produits, l’un d’entre eux s’est soudainement démodé et a été supprimé.
405 Méthode non autorisée - vous ne pouvez pas faire cela
Ce type d'exception est directement lié au verbe utilisé dans la requête (GET, PUT, POST, DELETE), qui, à son tour, indique l'action que nous essayons d'effectuer avec la ressource. Si la ressource demandée ne prend pas en charge l'action spécifiée, le serveur le dit explicitement.
422 Entité non traitable - corriger et renvoyer
Une des exceptions les plus utiles. Renvoyé chaque fois qu'il y a des erreurs logiques dans les données de la demande. Par données de requête, nous entendons soit un ensemble de paramètres et leurs valeurs correspondantes transmis par la méthode GET, soit des champs d'un objet transmis dans le corps de la requête par les méthodes POST, PUT et DELETE. Si les données n'ont pas été validées, le serveur renvoie un rapport dans la section « données » indiquant quels paramètres sont invalides et pourquoi.
Le protocole HTTP prend en charge beaucoup plus grand nombre divers codes de statut pour toutes les occasions, mais dans la pratique, ils sont rarement utilisés et dans le contexte de l'API Web ne sont d'aucune utilité pratique. Dans ma mémoire, je n’ai jamais eu à aller au-delà de la liste d’exceptions ci-dessus.
Demandes
Récupération des éléments de collection
L’une des demandes les plus courantes est la demande d’obtention d’éléments de collection. L'application client affiche des flux d'informations, des listes de produits, diverses informations et tableaux statistiques et bien plus encore en accédant aux ressources de collecte. Pour faire cette requête, nous accédons à la collection en utilisant la méthode GET et en passant des paramètres supplémentaires dans la chaîne de requête. Comme nous l'avons déjà indiqué plus haut, en réponse nous attendons de recevoir un ensemble d'éléments de collection homogènes et les informations nécessaires à la pagination - chargement de la suite de la liste ou de sa page spécifique. Le contenu de la sélection peut être spécialement limité et trié à l'aide du transfert paramètres supplémentaires. Ils seront discutés plus loin.
Navigation dans les pages
page- le paramètre indique quelle page doit être affichée. Si ce paramètre n'est pas passé, alors la première page s'affiche. Dès la première réponse réussie du serveur, le nombre de pages de la collection avec les paramètres de filtrage actuels sera clair. Si la valeur dépasse le nombre maximum de pages, il est préférable de renvoyer une erreur 404 Non trouvé.
OBTENIR /api/v1/news?page=1
par page- indique le nombre d'éléments souhaité sur la page. Généralement, l'API a sa propre valeur par défaut, qui est renvoyée sous forme de champ perPage dans la section de pagination, mais dans certains cas, elle vous permet d'augmenter cette valeur jusqu'à des limites raisonnables en fournissant la valeur maximale maxPerPage :
OBTENIR /api/v1/news?perPage=100
Tri des résultats
Souvent, vous souhaitez trier les résultats d'une sélection par valeurs ascendantes ou décroissantes de certains champs prenant en charge le tri comparatif (pour les champs numériques) ou alphabétique (pour les champs de chaîne). Par exemple, nous devons organiser une liste d'utilisateurs par nom ou de produits par prix. De plus, nous pouvons définir le sens de tri de A à Z ou dans le sens opposé, et il est différent selon les champs.
Trier par- il existe plusieurs approches pour transmettre des données de tri complexes dans les paramètres GET. Ici, il est nécessaire d'indiquer clairement l'ordre et le sens de tri.
Certaines API suggèrent de le faire sous forme de chaîne :
OBTENIR /api/v1/products?sortBy=name.desc,price.asc
D'autres options suggèrent d'utiliser un tableau :
OBTENIR /api/v1/products ? sortBy=nom& sortBy=desc& sortBy=prix& sortBy=asc
En général, les deux options sont équivalentes, puisqu’elles véhiculent les mêmes instructions. À mon avis, l'option avec un tableau est plus universelle, mais, comme on dit, cela dépend du goût et de la couleur...
Filtrage simple par valeur
Afin de filtrer une sélection par la valeur d'un champ, il suffit dans la plupart des cas de passer le nom du champ et la valeur souhaitée comme paramètre de filtre. Par exemple, nous souhaitons filtrer les articles par identifiant d'auteur :
OBTENIR /api/v1/articles?authorId=25
Options de filtrage avancées
De nombreuses interfaces nécessitent des systèmes de filtrage et de recherche plus complexes. Je vais énumérer les options de filtrage principales et les plus courantes.
Filtrage par limites supérieure et inférieure à l'aide d'opérateurs de comparaison de (supérieur ou égal à), supérieur (supérieur à), à (inférieur ou égal à), inférieur (inférieur à). S'applique aux champs dont les valeurs peuvent être classées.
OBTENIR /api/v1/products?price=500&price=1000
Filtrez par plusieurs valeurs possibles de la liste. S'applique aux champs dont l'ensemble des valeurs possibles est limité, par exemple un filtre par plusieurs statuts :
OBTENIR /api/v1/products?status=1&status=2
Filtrage par correspondance de chaîne partielle. S'applique aux champs contenant des données textuelles ou des données pouvant être assimilées à du texte, telles que des références numériques de produits, des numéros de téléphone, etc.
GET /api/v1/users?name=Jean GET /api/v1/products?code=123
Filtres nommés
Dans certains cas, lorsque certains ensembles de paramètres de filtre sont souvent utilisés et sont impliqués par le système comme quelque chose d'holistique, surtout s'ils affectent la mécanique interne, souvent complexe, de l'échantillonnage, il est conseillé de les regrouper dans ce que l'on appelle des filtres nommés. Il suffit de transmettre le nom du filtre dans la requête et le système construira automatiquement la sélection.
GET /api/v1/products?filters=recommandé
Les filtres nommés peuvent également avoir leurs propres paramètres.
OBTENIR /api/v1/products?filters=kidds
Dans cette sous-section, j'ai essayé de parler des options et méthodes les plus populaires pour obtenir l'échantillon requis. Très probablement, dans votre pratique, il y aura beaucoup plus d'exemples et de nuances concernant ce sujet. Si vous avez quelque chose à ajouter à mon matériel, j'en serai ravi. Entre-temps, le poste a déjà pris une ampleur significative, nous analyserons donc d'autres types de demandes dans un proche avenir.
Quelle que soit la manière dont le concept d'architecture client-serveur est défini (et il existe de nombreuses définitions de ce type dans la littérature), la base de ce concept est un modèle informatique distribué. Dans le cas le plus général, sous client Et serveur deux processus en interaction sont compris, dont l’un fournit un service à l’autre.
Le terme « client-serveur » désigne une architecture d'un progiciel dans laquelle ses parties fonctionnelles interagissent selon le schéma « requête-réponse ». Si nous considérons deux parties en interaction de ce complexe, alors l'une d'elles (le client) effectue fonction active, c'est-à-dire qu'il initie des requêtes et que l'autre (le serveur) y répond passivement. Au fur et à mesure que le système se développe, les rôles peuvent changer, par exemple, certains blocs logiciels rempliront simultanément les fonctions de serveur par rapport à un bloc et de client par rapport à un autre.
Serveur - un ou plusieurs processeurs multi-utilisateurs avec un seul champ mémoire, qui, selon les besoins de l'utilisateur, leur assure les fonctions de calcul, de communication et d'accès aux bases de données. Serveur peut être appelé un programme qui fournit certains services à d'autres programmes. Des exemples de serveurs sont le serveur Web Apache, les serveurs de bases de données - MySQL, ORACLE, les systèmes de fichiers réseau et les imprimantes Windows.
Client - un poste de travail pour un utilisateur, fournissant le mode d'enregistrement et d'autres fonctions nécessaires sur son lieu de travail - calculs, communication, accès aux bases de données, etc. Un client peut être appelé un programme qui utilise le service fourni par le programme serveur. Exemples de clients - MSIE (MS Internet Explorer), client ICQ.
Souvent, les gens se réfèrent simplement à l'ordinateur sur lequel l'un de ces programmes s'exécute en tant que client ou serveur.
Essentiellement, client et serveur sont des rôles joués par des programmes. Les clients et les serveurs peuvent résider physiquement sur le même ordinateur. Le même programme peut être à la fois client et serveur, etc... ce ne sont que des rôles.
Si l'on fait une analogie avec la société - une banque ou un magasin - les « serveurs ». Ils fournissent certains services à leurs clients. Mais la banque peut en même temps être cliente d'une autre entreprise, etc...
Le traitement client-serveur est un environnement dans lequel le traitement des applications est réparti entre un client et un serveur. Souvent, différents types de machines sont impliqués dans le traitement, le client et le serveur communiquant entre eux à l'aide d'un ensemble fixe de protocoles d'échange standard et de procédures pour accéder aux plates-formes distantes.
Les SGBD provenant d'ordinateurs personnels (tels que Clipper, DBase, FoxPro, Paradox, Clarion) ont des versions réseau qui partagent simplement des fichiers de base de données des mêmes formats pour les PC, tout en implémentant des verrous réseau pour restreindre l'accès aux tables et aux enregistrements. Cependant, tout le travail est effectué sur un PC. Le serveur est utilisé simplement à titre général disque distant grande capacité. Cette façon de travailler entraîne un risque de perte de données due à des pannes matérielles.
Par rapport à de tels systèmes, les systèmes construits dans l'architecture Client-Serveur présentent les avantages suivants :
vous permettre d'augmenter la taille et la complexité des programmes exécutés sur un poste de travail ;
assure le transfert des opérations les plus gourmandes en main d'œuvre vers un serveur, qui est une machine dotée d'une plus grande puissance de calcul ;
minimise la possibilité de perte d'informations contenues dans la base de données grâce à l'utilisation de mécanismes internes de protection des données disponibles sur le serveur, tels que, par exemple, les systèmes de traçage des transactions, la restauration après une panne et les moyens d'assurer l'intégrité des données ;
réduit la quantité d'informations transmises plusieurs fois sur le réseau.
Dans une architecture client-serveur, le serveur de base de données fournit non seulement l'accès aux données partagées, mais gère également tout le traitement de ces données. Le client envoie des requêtes au serveur pour lire ou modifier des données, qui sont formulées dans Langage SQL. Le serveur fait tout lui-même Les changements nécessaires ou des échantillons, tout en surveillant l’intégrité et la cohérence des données, et les résultats sous forme d’un ensemble d’enregistrements ou d’un code retour sont envoyés à l’ordinateur du client.
1.2. Histoire…
L'architecture et le terme « client-serveur » ont été utilisés pour la première fois au début des années 80. Les premières applications dotées d'une architecture client-serveur étaient les bases de données.
Avant cela, il n'y avait pas de division claire - le programme faisait généralement tout lui-même - y compris travailler avec les données dans le système de fichiers, présenter les données à l'utilisateur, etc. Au fil du temps, le volume et la criticité des données pour l'entreprise ont augmenté, et ce au fil du temps. a commencé à donner lieu à des problèmes (performances, sécurité et autres).
Ensuite, ils ont décidé qu'il serait pratique d'installer la base de données sur un ordinateur séparé puissant (serveur) et de permettre à cette base de données d'être utilisée par de nombreux utilisateurs d'un petit ordinateur (clients) via le réseau, ce qui a été fait.
Essentiellement, « l’explosion » de la popularité de la technologie client-serveur a été provoquée par l’invention par IBM d’un langage de requête simple pour les bases de données relationnelles. Données SQL. Aujourd'hui, SQL est la norme universelle pour travailler avec des bases de données. Récemment, cette « explosion » s'est poursuivie avec l'invention d'Internet, dans lequel chaque interaction se produit littéralement selon une architecture « client-serveur ».
1.3. Protocoles
Le serveur et le client du réseau « parlent » entre eux dans un « langage » (au sens large du terme) compréhensible par les deux parties. Ce « langage » s’appelle un protocole.
Dans le cas d'une banque, le protocole peut être appelé les formulaires que le client remplit.
Dans notre cas, exemples de protocoles :
FTP (protocole de transfert de fichiers)
HTTP (protocole de transfert hypertexte)
SMTP (protocole de transfert de courrier simple)
IP (protocole Internet)
Protocole client/serveur MySQL
Notez que les protocoles peuvent être à différents niveaux. Les systèmes de classification des niveaux peuvent être différents, mais l'une des lignes les plus connues est l'OSI (Open Systems Interconnection), qui comporte 7 niveaux.
Par exemple, HTTP est un protocole de couche d'application (septième plus élevé) et IP est un protocole de couche réseau (troisième).
1.4. Répartition des fonctions dans l'architecture client-serveur
Dans une architecture client-serveur classique, les trois parties principales de l'application doivent être réparties sur deux modules physiques. Généralement, le logiciel de stockage de données est situé sur un serveur (par exemple, un serveur de base de données), l'interface utilisateur est côté client, mais le traitement des données doit être réparti entre les parties client et serveur. C'est le principal inconvénient de l'architecture à deux niveaux, qui entraîne plusieurs fonctionnalités désagréables qui compliquent grandement le développement de systèmes client-serveur.
Le processus de développement de tels systèmes est assez complexe et l'une des tâches les plus importantes est la décision sur la manière dont les fonctionnalités de l'application doivent être réparties entre les parties client et serveur. En essayant de résoudre ce problème, les développeurs disposent d'architectures à deux, trois et plusieurs niveaux. Tout dépend du nombre de liens intermédiaires inclus entre le client et le serveur.
La tâche principale résolue par l'application client est de fournir une interface avec l'utilisateur, c'est-à-dire de saisir des données et de présenter les résultats sous une forme conviviale, ainsi que de gérer des scénarios d'application.
Les principales fonctions d'un SGBD serveur sont d'assurer la fiabilité, la cohérence et la sécurité des données, de gérer les requêtes des clients et de traiter rapidement les requêtes SQL.
Toute la logique de l'application - tâches applicatives, règles métier - dans une architecture à deux niveaux est répartie par le développeur entre deux processus : client et serveur (Fig. 1).
Au début, la plupart des fonctions de l'application étaient résolues par le client, le serveur n'étant impliqué que dans le traitement des requêtes SQL. Cette architecture est appelée « client lourd – serveur léger ».
L'émergence de la possibilité de créer des procédures stockées sur le serveur, c'est-à-dire des programmes compilés avec une logique de fonctionnement interne, a conduit à une tendance à transférer une partie croissante des fonctions vers le serveur. Le serveur est devenu de plus en plus « gros » et le client est devenu « plus mince ».
Cette solution présente des avantages évidents, par exemple, elle est plus facile à maintenir, puisque toutes les modifications doivent être effectuées au même endroit : sur le serveur.
Les modèles évoqués ci-dessus présentent les inconvénients suivants.
1. Client « épais » :
– complexité de l'administration ;
– la mise à jour du logiciel devient plus compliquée, puisqu'il faut le remplacer simultanément sur l'ensemble du système ;
– la répartition des pouvoirs devient plus compliquée, puisque l'accès n'est pas limité par des actions, mais par des tables ;
– le réseau est surchargé en raison de la transmission de données non traitées à travers celui-ci ;
– une faible protection des données, car il est difficile de répartir correctement les pouvoirs.
2. Serveur « gros » :
– la mise en œuvre devient plus compliquée, car les langages comme PL/SQL ne sont pas adaptés au développement de tels logiciels et il n'existe pas de bons fonds débogage ;
– les performances des programmes écrits dans des langages comme PL/SQL sont nettement inférieures à celles créées dans d’autres langages, ce qui est important pour les systèmes complexes ;
– les programmes écrits dans les langages SGBD ne fonctionnent généralement pas de manière fiable ; une erreur dans ceux-ci peut entraîner la panne de l'ensemble du serveur de base de données ;
– les programmes résultants sont totalement inportables sur d’autres systèmes et plates-formes.
Pour résoudre ces problèmes, des architectures client-serveur à plusieurs niveaux (trois niveaux ou plus) sont utilisées. Une architecture client-serveur à plusieurs niveaux peut simplifier considérablement l'informatique distribuée, la rendant non seulement plus fiable, mais également plus accessible.
Cependant, le langage dans lequel les procédures stockées sont écrites n’est ni suffisamment puissant ni suffisamment flexible pour implémenter facilement une logique d’application complexe.
Ensuite, il y avait une tendance à confier l'exécution des tâches d'application et des règles métier à un composant d'application distinct (ou plusieurs composants), qui peuvent s'exécuter soit sur un ordinateur spécialement dédié - le serveur d'applications, soit sur le même ordinateur sur lequel s'exécute le serveur de base de données. . C’est ainsi qu’ont émergé les architectures client-serveur à trois niveaux et à plusieurs niveaux.
Riz. 1. Répartition des fonctions entre client et serveur
Il y avait une spéciale logiciel Middleware (logiciel) qui doit permettre aux multiples composants d'une telle application multi-composants de fonctionner ensemble. De telles applications sont flexibles, évolutives, mais difficiles à développer.
BIBLIOGRAPHIE
Informatique / Éd. N.V. Makarova – M. : Finances et statistiques, 1998.
Evdokimov V.V. et autres Informatique économique. Saint-Pétersbourg : Peter, 2004.
Kazakov S.I. Les bases technologies de réseau– M. : Radio et Communications, 2004.
Kogalovsky M.R., Technologie des bases de données sur ordinateurs personnels, - M. : Finances et Statistiques, 2003.
Popov V.V. Les bases la technologie informatique. –M. : Finances et Statistiques, 2001.
Figurnov V.E. IBM PC pour l'utilisateur. M., 2000.
SYSTÈME D'EXPLOITATION MS-DOS. CONCEPTS DE BASE ET COMMANDES CONCEPTS DE BASE : BASE DE DONNÉES, SGBD, ENTITÉ, ATTRIBUT, RELATION (UN-À-UN, UN-À-PLUSIEURS, PLUSIEURS-À-MANIEUX), RELATION, CLÉ PRIMAIRE
La technologie client-serveur prévoit la présence de deux processus indépendants en interaction - un serveur et un client, dont la communication s'effectue via le réseau.
Les serveurs sont des processus chargés de prendre en charge et système de fichiers, et les clients sont des processus qui envoient une requête et attendent une réponse du serveur.
Le modèle client-serveur est utilisé lors de la construction d'un système basé sur un SGBD, ainsi que de systèmes de messagerie. Il existe également une architecture dite serveur de fichiers, qui diffère considérablement de l'architecture client-serveur.
Les données d'un système de serveur de fichiers sont stockées sur un serveur de fichiers (Novell NetWare ou WindowsNT Server) et sont traitées sur les postes de travail via le fonctionnement de « SGBD de bureau » tels qu'Access, Paradox, FoxPro, etc.
Le SGBD est situé sur un poste de travail et la manipulation des données est effectuée par plusieurs processus indépendants et incohérents. Toutes les données sont transférées du serveur via le réseau vers le poste de travail, ce qui ralentit la vitesse de traitement des informations.
La technologie client-serveur est mise en œuvre par le fonctionnement de deux (au moins) applications - clients et serveur, qui partagent des fonctions entre elles. Le serveur est responsable du stockage et de la manipulation directe des données, par exemple SQLServer, Oracle, Sybase et autres.
L'interface utilisateur est constituée par le client, qui est basé sur des outils spéciaux ou des SGBD de bureau. Le traitement logique des données est effectué en partie sur le client et en partie sur le serveur. Les requêtes sont envoyées au serveur par le client, généralement en SQL. Les requêtes reçues sont traitées par le serveur et le résultat est renvoyé au(x) client(s).
Dans ce cas, les données sont traitées au même endroit où elles sont stockées - sur le serveur, de sorte qu'une grande partie d'entre elles n'est pas transmise sur le réseau.
Avantages de l'architecture client-serveur
La technologie client-serveur apporte les qualités suivantes à un système d'information :
- Fiabilité
La modification des données est effectuée par le serveur de base de données à l'aide du mécanisme de transaction, qui confère à l'ensemble des opérations des propriétés telles que : 1) l'atomicité, qui garantit l'intégrité des données à la fin de la transaction ; 2) indépendance des transactions des différents utilisateurs ; 3) résistance aux échecs - sauvegarde des résultats de l'achèvement de la transaction.
- L'évolutivité, c'est-à-dire la capacité du système à être indépendant du nombre d'utilisateurs et des volumes d'informations sans remplacer le logiciel utilisé.
La technologie client-serveur prend en charge des milliers d'utilisateurs et des gigaoctets d'informations avec la plate-forme matérielle appropriée.
- La sécurité, c'est-à-dire protection fiable Information provenant de
- La flexibilité. Dans les applications qui fonctionnent avec des données, il existe des couches logiques : interface utilisateur ; règles de traitement logique ; Gestion de données.
Comme déjà indiqué, dans la technologie des serveurs de fichiers, les trois couches sont combinées en une seule application monolithique exécutée sur un poste de travail, et tous les changements dans les couches conduisent nécessairement à une modification de l'application, les versions du client et du serveur diffèrent, et c'est nécessaire de mettre à jour les versions sur tous les postes .
La technologie client-serveur dans une application à deux niveaux permet l'exécution de toutes les fonctions de création sur le client et de toutes les fonctions de gestion des informations de base de données sur le serveur ; les règles métier peuvent être implémentées à la fois sur le serveur et sur le client.
Une application à trois niveaux permet un niveau intermédiaire qui implémente les règles métier, qui sont les composants les plus modifiables.
Plusieurs niveaux vous permettent d'adapter votre application existante de manière flexible et rentable aux exigences commerciales en constante évolution.
Architecture client-serveur est conçu pour résoudre les problèmes des applications de serveur de fichiers en séparant les composants d'application et en les plaçant là où ils fonctionneront le plus efficacement. Une caractéristique de l'architecture client-serveur est l'utilisation de serveurs de bases de données dédiés qui comprennent les requêtes dans un langage structuré. Requêtes SQL(Structured Query Language) et rechercher, trier et agréger des informations.
Particularité serveurs de base de données - la présence d'un répertoire de données, qui enregistre la structure de la base de données, les restrictions d'intégrité des données, les formats et même les procédures du serveur pour le traitement des données par appel ou par événements dans le programme.
Les objets de développement dans de telles applications, outre la logique de dialogue et de traitement, sont avant tout le modèle de données relationnelles et l'ensemble d'instructions SQL associé pour les requêtes de base de données typiques.
La plupart des configurations client-serveur utilisent un modèle à deux niveaux dans lequel le client accède aux services du serveur. On suppose que les composants de dialogue PS et PL sont hébergés sur le client pour fournir une interface graphique. Les composants de gestion des données DS et FS sont situés sur le serveur, et les logiques de dialogue (PS, PL), BL et DL sont situées sur le client. La définition à deux niveaux de l'architecture client-serveur utilise exactement cette option : l'application s'exécute sur le client, le SGBD sur le serveur (Fig. 1.4.).
Riz. 6. La version classique d'un système d'information client-serveur
Étant donné que ce schéma impose le moins de demandes au serveur, il offre la meilleure évolutivité. Cependant, les applications complexes qui impliquent de nombreuses interactions avec les bases de données peuvent imposer une lourde charge à la fois au client et au réseau. Les résultats de la requête SQL doivent être renvoyés au client pour traitement car c'est là que réside la logique de décision. Cette conception entraîne une complexité supplémentaire dans l'administration des applications dispersées sur différents nœuds clients. Pour réduire la charge du réseau et simplifier l'administration des applications, le composant BL peut être hébergé sur un serveur. Dans ce cas, toute la logique décisionnelle est formalisée sous la forme procédures stockées et s'exécute sur le serveur de base de données.
Procédure stockée- une procédure avec des instructions SQL d'accès à la base de données, appelées par son nom, transmettant les paramètres requis et exécutées sur le serveur de base de données.
Les procédures stockées peuvent être compilées, ce qui augmente leur vitesse d'exécution et réduit la charge sur le serveur. Les procédures stockées améliorent l’intégrité des applications et des bases de données et garantissent que les opérations et calculs partagés sont à jour. La prise en charge de ces procédures est améliorée, ainsi que la sécurité (il n'y a pas d'accès direct aux données).
NOTE
Sachez que la surcharge des procédures stockées avec la logique de l'application peut surcharger le serveur, entraînant une perte de performances. Ce problème est particulièrement pertinent lors du développement de grands systèmes d'information dans lesquels un grand nombre de clients peuvent accéder simultanément au serveur. Par conséquent, dans la plupart des cas, des décisions de compromis doivent être prises : une partie de la logique de l'application doit être placée du côté serveur et une partie - du côté client. De tels systèmes client-serveur sont appelés systèmes logiques séparés. Ce schéma Avec une séparation logique réussie, cela vous permet d'obtenir une charge plus équilibrée sur les clients et les serveurs, mais en même temps, cela rend la maintenance des applications plus difficile.
La création d'une architecture client-serveur est également possible sur la base d'un système multi-terminal. Dans ce cas, les programmes utilisateur sont exécutés dans un environnement de serveur d'applications multitâches et les nœuds clients sont dégénérés et représentés par des terminaux. Un schéma de système d'information similaire est typique pour UNIX.
Actuellement, l'architecture client-serveur est reconnue et largement utilisée comme moyen d'organiser des applications pour les groupes de travail et les systèmes d'information au niveau de l'entreprise. Cette organisation du travail augmente l'efficacité de l'exécution des applications en utilisant les capacités du serveur de base de données, en déchargeant le réseau et en assurant le contrôle de l'intégrité des données.
Les conceptions d'architecture client-serveur à deux niveaux peuvent entraîner certains problèmes dans les applications d'informations complexes comportant de nombreux utilisateurs et une logique complexe. La solution à ces problèmes peut être l’utilisation d’une architecture multi-niveaux.
Architecture en couches
L'architecture multiniveau est un développement de l'architecture client-serveur et, dans sa forme classique, se compose de trois couches :
· le niveau inférieur représente les applications client dédiées à l'exécution des fonctions et de la logique des vues PS et PL et ayant interface logicielle appeler une application au niveau intermédiaire ;
· niveau moyen est un serveur d'applications sur lequel la logique d'application BL s'exécute et à partir de laquelle la logique de traitement de données DL appelle les opérations de base de données DS ;
· Le niveau supérieur est un serveur de base de données dédié à distance dédié aux services de traitement de données DS et aux opérations sur les fichiers FS (sans risque d'utiliser des procédures stockées).
Un concept similaire de traitement des données est notamment promu par Oracle, Sun, Borland et d'autres.
L'architecture à trois niveaux équilibre davantage la charge entre les différents nœuds et le réseau, favorise la spécialisation des outils pour le développement d'applications et élimine les défauts du modèle client-serveur à deux niveaux.
La centralisation de la logique applicative simplifie l’administration et la maintenance. Les plateformes et outils de mise en œuvre de l'interface et de la logique applicative sont clairement séparés, ce qui permet de les mettre en œuvre par des spécialistes avec la plus grande efficacité profil étroit. Enfin, les modifications apportées à la logique de l'application n'affectent pas l'interface, et vice versa. Mais comme les frontières entre les composants PL, BL et DL sont floues, la logique d'application peut apparaître aux trois niveaux. Le serveur d'applications, à l'aide d'un moniteur de transactions, fournit une interface avec les clients et autres serveurs, peut gérer les transactions et garantir l'intégrité. base distribuée données. Les outils d'appel de procédure à distance sont les plus cohérents avec l'idée d'informatique distribuée : ils assurent un appel depuis n'importe quel nœud du réseau vers une procédure applicative située sur un autre nœud, le transfert de paramètres, le traitement à distance et le retour des résultats.
Avec la croissance des systèmes client-serveur, la nécessité de trois couches devient de plus en plus évidente. Les produits d'architecture à trois niveaux, appelés moniteurs de transactions, sont relativement nouveaux. Ces outils sont principalement axés sur l'environnement UNIX, mais les serveurs d'applications peuvent être créés sur Microsoft Windows NT à l'aide d'appels de procédure distante pour communiquer entre les clients et le serveur d'applications. En pratique dans réseau local des architectures mixtes (à deux et trois niveaux) avec le même serveur de base de données peuvent être utilisées. Prendre en compte connexions mondiales l'architecture peut avoir plus de trois liens. Actuellement, de nouveaux outils sont apparus pour une segmentation flexible des applications client-serveur sur différents nœuds de réseau.
Ainsi, l'architecture en couches applications distribuées permet d'augmenter l'efficacité du système d'information de l'entreprise et d'optimiser la répartition de ses ressources logicielles et matérielles. Mais pour l’instant, l’architecture client-serveur domine toujours le marché russe.
Technologies Internet/Intranet
Dans le développement de la technologie Internet/Intranet, l'accent est mis jusqu'à présent sur le développement d'instruments logiciel. Dans le même temps, il existe un manque d'outils développés pour développer des applications fonctionnant avec des bases de données.
Une solution de compromis pour créer des systèmes d'information pratiques, faciles à utiliser et à entretenir qui fonctionnent efficacement avec des bases de données était la combinaison de la technologie Internet/Intranet avec une architecture à plusieurs niveaux. Dans ce cas, la structure de l'application d'information prend la forme suivante : navigateur - serveur d'applications - serveur de base de données - serveur pages dynamiques- serveur Web. Grâce à l'intégration de la technologie Internet/intranet et de l'architecture client-serveur, le processus de mise en œuvre et de maintenance d'un système d'information d'entreprise est considérablement simplifié tout en conservant une efficacité et une simplicité assez élevées. partage information.
Domaines d'application et exemples de mise en œuvre de systèmes d'information
Au cours des dernières années, l'ordinateur est devenu partie intégrante Système de gestion entreprises. Cependant, l’approche moderne du management implique également d’investir dans les technologies de l’information. De plus, plus l’entreprise est grande, plus ces investissements devraient être importants.
Grâce au développement rapide des technologies de l'information, le champ d'application de leurs applications s'élargit. Si auparavant c'était presque le seul domaine dans lequel ils étaient utilisés Systèmes d'information, il y a eu l'automatisation de la comptabilité, nous assistons maintenant à l'introduction des technologies de l'information dans de nombreux autres domaines. Utilisation efficace les systèmes d'information d'entreprise permettent de faire des prévisions plus précises et d'éviter d'éventuelles erreurs de gestion. De nombreuses informations utiles peuvent être extraites de toutes données et rapports sur le fonctionnement d'une entreprise. Et les systèmes d'information permettent de tirer le meilleur parti de toutes les informations disponibles dans l'entreprise. C'est ce fait qui explique la viabilité et le développement rapide des technologies de l'information - les entreprises modernes sont extrêmement sensibles aux erreurs de gestion, et afin de prendre des décisions de gestion compétentes dans des conditions d'incertitude et de risque, il est nécessaire de garder constamment sous contrôle divers aspects de les activités financières et économiques de l'entreprise (quel que soit le profil de ses activités).
Par conséquent, on peut raisonnablement affirmer que dans une période difficile concours Une entreprise qui utilise les technologies de l’information modernes dans sa gestion a de grandes chances de gagner.
Examinons les tâches les plus importantes pouvant être résolues à l'aide d'un logiciel spécial.
Toute personne ayant travaillé avec un ordinateur a entendu parler de la technologie client-serveur. Cette technologie repose sur deux concepts principaux : client et serveur. Le client est un ordinateur qui demande au serveur d'effectuer des actions ou de fournir des informations. Un serveur est un ordinateur, généralement plus puissant que l'ordinateur client. Le modèle de fonctionnement d'un tel système est le suivant : le client fait une requête au serveur, le serveur (partie serveur) reçoit la requête, l'exécute et envoie le résultat au client (partie client).
Le serveur peut servir plusieurs clients simultanément. Dans ce cas, nous parlons de mode multi-utilisateurs. Ne prenez pas le mot « simultanément » au sens littéral. Les requêtes sont exécutées par le serveur de manière séquentielle. Si plusieurs demandes arrivent en même temps, elles sont mises en file d'attente. Dans ce cas, la file d'attente est une liste de demandes client en attente. Parfois, les demandes peuvent avoir des priorités. La priorité est le niveau « d'importance » de l'exécution d'une demande. Les demandes avec des priorités plus élevées doivent être traitées plus tôt.
Il existe une petite exception concernant le traitement séquentiel. salle d'opération Système Windows est multitâche et multithread. Le multitâche est la capacité d'un système d'exploitation à exécuter plusieurs applications personnalisées(programmes).
Cela signifie que plusieurs tâches peuvent être exécutées sur le serveur, chacune pouvant exécuter sa propre requête distincte. Le multithreading permet d'exécuter plusieurs requêtes au sein d'une seule tâche. Qu'est-ce que cela donne ? - Il y a une augmentation des performances du serveur.
Le cycle d'exécution de la requête consiste à envoyer une requête et une réponse entre le client et le serveur et à exécuter directement cette requête sur le serveur.
En règle générale, l'exécution d'une requête (requête complexe) prend plus de temps que le temps nécessaire pour transmettre la requête et le résultat. Par conséquent, les serveurs utilisent des systèmes pour distribuer les transactions (demandes) entre les domaines (parties) du serveur. Une transaction est un ensemble de commandes qui sont soit toutes exécutées, soit aucune n'est exécutée. Un domaine est un élément de serveur. Souvent le serveur est allumé niveau physique n'en est pas un, mais un groupe d'ordinateurs combinés en un seul système pour prendre en charge toutes les opérations. Dans ce cas, le domaine est l'ordinateur qui fait partie de l'architecture du serveur.
Il existe des concepts pour construire un système client-serveur :
1) Client faible - serveur puissant - tout le traitement des informations est entièrement effectué par le serveur. Le serveur envoie le résultat final, qui ne nécessite aucun traitement supplémentaire. Le client dialogue uniquement avec l'utilisateur : crée une requête, envoie une requête, accepte une requête et affiche des informations à l'écran (vers une imprimante, vers un fichier).
2) Client fort - une partie du traitement de l'information est déléguée au client.
Un exemple simple : un utilisateur a besoin d'une liste des employés de l'entreprise, triés par nom de famille. Dans le premier cas, le serveur, à la demande du client, récupère les noms (par exemple dans une base de données) et les trie lui-même. La liste triée terminée est envoyée au client. Le client n'a qu'à afficher l'écran. Dans le second cas, le serveur récupère uniquement les noms de famille et envoie les données au client. Le client trie la liste et l'affiche à l'écran.
Mais ce n'est pas tout. Disons que l'utilisateur souhaite trier la liste résultante par niveau de salaire. Dans le premier cas, le client génère nouvelle requête au serveur, le serveur l'exécute et envoie la réponse prête au client, qui ne l'affiche qu'à l'écran. Dans le second cas, le client trie lui-même la liste sans contacter le serveur. Naturellement, dans le second cas, le serveur sera moins chargé.
Il existe un autre concept important : le « temps d'attente ». Le « Temps d'attente » est le temps au bout duquel un utilisateur, ayant envoyé une requête au serveur, recevra une réponse de sa part. Le temps d'attente est l'indicateur le plus important de la performance d'un système qui met en œuvre le concept client-serveur.
Lorsque les données sont partiellement traitées sur le client, le « temps d'attente » est moindre. Il est plus petit du fait de la simplification de la requête et de son temps d’exécution. Il y a donc moins d’attente dans la file d’attente pour exécuter la requête.
Bien entendu, le temps de traitement final sur le client peut être légèrement plus élevé en raison de la différence de performances du serveur. Cela peut entraîner des délais d'attente légèrement plus longs. Au final, c'est quand même plus rentable, car... le temps d'attente dans la file d'attente des requêtes sur le serveur est moindre.
De nombreux serveurs ne peuvent pas supporter la charge (la « pression » des requêtes) et se bloquent tout simplement. Dans ce cas, il existe deux voies alternatives : augmenter la productivité et transférer une partie des opérations sur les données au client. En règle générale, l’augmentation de la productivité est une opération beaucoup plus coûteuse et, en ce sens, limitée. Il ne reste plus qu'à « décharger » le serveur et transférer une partie du traitement des données au client.
P.S. Souvent, un certain nombre d’organisations utilisent délibérément des ordinateurs obsolètes comme serveurs. Ils conviennent parfaitement au stockage de fichiers, aux serveurs d'impression (une imprimante de bureau y est connectée), aux serveurs WEB (serveurs Internet), aux petites bases de données (partie serveur). Cela se justifie d’un point de vue économique.
Application du plus ordinateurs puissants Il est conseillé de servir de serveurs dans le secteur bancaire, car le volume des paiements est en constante augmentation. En conséquence, la quantité requise de ressources informatiques augmente. La « lutte » pour une augmentation de quelques pour cent de la productivité est ici justifiée.
Sergueï SOKOLOV (BSUIR)