Ces points de connaissances fondamentaux doivent être maîtrisés en communication front-end et back-end !

Qu'est-ce qui est reposant ?

Restful est la spécification de conception d'interface la plus populaire à l'heure actuelle. C'est une spécification que le front-end et le back-end doivent connaître. Cette spécification définit que dans le développement d'interfaces, dans chaque processus,

de protocole

doit utiliser lors de la communication avec le back-end. -end via l'API L'

de nom de domaine

doit être déployée sous un nom de domaine dédié et doit rester aussi simple que possible. Si vous êtes sûr que l'API est très simple et ne sera pas développée davantage, vous pouvez envisager de la placer sous le nom de domaine principal. Voici deux exemples courants de racine d'URL :

• api.example.com/* Un nom de sous-domaine distinct est utilisé pour. accéder à l'interface
• example.com/api /* Toutes les API dans une

version à espace unique (Versioning)

doivent rester rétrocompatibles. Vous devez introduire les nouvelles versions des API tout en vous assurant que les anciennes versions des API sont toujours disponibles. Par conséquent, une

adresse de support de version (chemin) doit être fournie pour l'URL spécifique de l'

API de routage (routeur).

• Le nom de l'URL doit être entièrement en minuscules
• . Le nom de la ressource (ressource) dans l'URL doit être un nom, et doit être au pluriel.
• Les URL de type restful doivent être utilisées en premier
• . Il doit s'agir d'une URL facile à lire
• et ne doit pas exposer l'architecture du serveur.

Quant à savoir si l'URL doit utiliser des traits d'union (-) ou des traits de soulignement (_), il n'y a pas de règle absolue, mais elle doit être cohérente avec un style basé sur la situation de l'équipe

• https://api.example com/zoos
• https://api.example.com/animals
• https://api.example. .com/zoos/{zoo}/animals
• https://api.example.com/animal_types
• https://api.example. com/employees

verbe (méthode de requête)

est un type d'opération spécifique pour les ressources, représenté par des verbes HTTP. . Il existe cinq verbes HTTP couramment utilisés (les commandes SQL correspondantes sont entre parenthèses).

• GET (SELECT) : Récupérer des ressources (un ou plusieurs éléments) du serveur.
• POST (CREATE) : Créez une nouvelle ressource sur le serveur.
• PUT (UPDATE) : Mettre à jour la ressource sur le serveur (le client fournit la ressource complète après la modification).
• PATCH (UPDATE) : Mise à jour dans la partie ressource de mise à jour du serveur (le client fournit des attributs modifiés).
• DELETE (DELETE) : Supprimer les ressources du serveur.

Paramètres d'URL

Tous les paramètres d'URL doivent être en minuscules et doivent utiliser le formulaire de paramètre de type trait de soulignement. Les paramètres de pagination doivent être fixés sur page et page_size.

La réponse (Réponse)

doit sélectionner un code d'état HTTP approprié.
Les données doivent être renvoyées au format JSON.
Toutes les erreurs doivent être formatées de manière uniforme.

Le code d'état commun

• 1xx signifie que la demande a été acceptée et doit continuer le traitement.
• 2xx n'apparaît généralement pas dans l'API. La demande a réussi et l'en-tête de réponse ou le corps de données attendu par la demande sera renvoyé avec cette réponse.
  • 200. Le serveur renvoie avec succès les données demandées par l'utilisateur.
  • 201 L'utilisateur crée une nouvelle ou modifie les données avec succès
  • 202 signifie qu'une demande est entrée dans la file d'attente en arrière-plan (il n'y a pas de valeur de retour en cas de succès, elle est asynchrone)
  • 204 Supprimer avec succès
• 3xx. Redirection
• 4xx Erreur causée par des raisons client
  • 404 L'interface demandée n'existe pas, type d'erreur (l'adresse de la demande est erronée)
  • 401 L'utilisateur n'est pas
  • connecté 403 L'utilisateur est connecté, mais n'a pas l'autorisation d'accéder
  • 422 Erreur de paramètre client, erreur de vérification
  • 429 Limite de requête dépassée
• 5xx Erreur causée par des raisons côté serveur
  • 500 Le serveur a rencontré une situation inattendue, qui l'a empêché de terminer la requête. Traitement, le code du serveur signale
  une
  • erreur 503. Le serveur est en maintenance
  • 504 Timeout
  .

format d'erreur

• • d'appel

'message' => ':message', // Description détaillée de l'erreur 'errors' => ':errors', // Description détaillée de l'erreur des paramètres, 422 et autres statuts fournissent 'code' => ' :code', // Code d'exception défini par l'entreprise 'status_code' => ':status_code', // Code d'état http 'debug' => ':debug', // Informations de débogage, l'environnement de non-production fournit

quel est le message ?

Les messages HTTP sont utilisés pour échanger des informations lors des requêtes et des réponses HTTP. Les messages qui transitent vers le serveur depuis le client

sont divisés en deux catégories : les messages de demande

et les messages de réponse. Les structures de base des messages de demande et de réponse sont les mêmes et elles sont composées de trois parties :

• Ligne de départ : effectue le traitement sur le serveur. message Description
• en-tête : quelques attributs
• Corps : données [facultatif]

axios

et le serveur de nœuds créent des XMLHttpRequests à partir du navigateur
La création de requêtes http à partir de node.js

prend en charge l'API Promise
Prend en charge l'interception des requêtes et des réponses, la conversion des données de requête et des données de réponse, l'annulation des requêtes, la conversion automatique de JSON, la prise en charge des données client pour la défense contre XSRF

, allez, étrangers (je ne suis pas étranger aux allées et venues, je l'espère ! vous sera utile)

Ce qui précède sont ces points de connaissances de base, qui doivent être maîtrisés dans la communication front-end et back-end ! Pour plus de détails, veuillez prêter attention aux autres articles connexes sur le site Web php chinois !