En outre, la ressource a au moins un URI comme condition pour que la ressource soit une ressource.

Caractéristiques du ROA

• Adressabilité
• Apatride
• Connectabilité
• Interface uniforme

Regardons chacun d'eux

Adressabilité

Les informations à fournir peuvent être exprimées via URI. Toutes les informations doivent avoir une adresse unique représentée par un URI.

Par exemple, si l'URI de base est: http://example.com

Si vous souhaitez connaître les informations d'un utilisateur spécifique http://example.com/users/1

Si vous voulez connaître les informations sur le chat http://example.com/cat

Si vous voulez connaître les informations de la souris http://example.com/mouse

Vous pouvez comprendre les informations à fournir simplement en regardant l'URI.

Apatride

Doit être un protocole client / serveur sans état basé sur HTTP. Les informations échangées peuvent être complètement interprétées par elles-mêmes sans gérer l'état des sessions.

Ceci est facile à comprendre l'analogie suivante

(Exemple avec état): Client: Bonjour Greffier: Bienvenue. Bienvenue chez XX Burger Client: je voudrais un ensemble de hamburgers Greffier: Que souhaitez-vous pour le menu latéral? Client: avec des pommes de terre Greffier: Qu'aimeriez-vous boire? Client: Chez Ginger Ale Greffier: Que diriez-vous de faire une boisson taille L pour +50 yens? Client: M va bien Greffier: Voulez-vous vraiment faire cela? Client: Oui Greffier: je suis intelligent

(Exemple sans état): Client: Bonjour Greffier: Bienvenue. Bienvenue chez XX Burger Client: je voudrais un ensemble de hamburgers Greffier: Que souhaitez-vous pour le menu latéral? Client: Veuillez me donner un ensemble de hamburgers avec des pommes de terre Greffier: Qu'aimeriez-vous boire? Client: Veuillez me donner un ensemble de hamburgers avec pommes de terre et soda au gingembre Greffier: Que diriez-vous de faire une boisson taille L pour +50 yens? Client: Veuillez me donner un ensemble de hamburgers avec pommes de terre et soda au gingembre (M) Greffier: Voulez-vous vraiment faire cela? Client: Veuillez me donner un ensemble de hamburgers avec pommes de terre et soda au gingembre (M). c'est tout Greffier: je suis intelligent

Si vous considérez le commis comme un serveur, il a toujours eu affaire à un client. Pendant ce temps, il n'est pas possible de répondre aux autres clients. Lorsque le magasin est bondé (lorsque l'accès augmente) Augmentez le nombre d'employés (serveur WEB supplémentaire) pour répondre.

Dans un magasin normal, un employé accepte toujours le même client dans une même caisse, Dans le cas du WEB, puisque plusieurs serveurs WEB reçoivent plusieurs clients en même temps, S'il s'agit d'un serveur sans état, un commis distinct sera affecté à chaque interaction comme décrit ci-dessus. Il devient possible de répondre à la commande du client.

Source Qu'est-ce qui est apatride

Connectivité

Être capable d'inclure d'autres informations ou des liens vers ces informations dans les informations.

Interface uniforme

Toutes les opérations d'information (obtenir, créer, mettre à jour, supprimer) sont des méthodes HTTP (GET, POST, PUT, DELETE) Utiliser.

GET Une méthode pour obtenir les informations de l'URI spécifié. Cela inclut l'obtention de pages Web, d'images, de vidéos et de flux.

POST POST a les trois rôles suivants.

1. Créez une ressource enfant pour la ressource parent

Par exemple, supposons que vous ayez une telle ressource de blog (parent). 　http://example.com/myblog

Ensuite, des entrées de blog individuelles (ressources enfants), 　http://example.com/myblog/entries/1

Peut être fourni comme.

2. Ajouter des données aux ressources

Ajoutez des données à une ressource existante. La différence avec la précédente est de savoir si les ressources ont une relation parent-enfant. http://example.com/myblog

3. Surcharge POST

Effectue un traitement qui ne peut pas être géré par d'autres méthodes. Cependant, cette utilisation s'écarte de l'interface unifiée dans ROA, il est donc préférable de ne pas l'utiliser autant que possible.

PUT Il existe deux façons d'utiliser PUT.

• Créer une nouvelle ressource
• Mettre à jour les ressources existantes

En regardant cela seul, il peut sembler que le rôle est similaire à POST.

Créer une ressource enfant pour la ressource parent = Créer une nouvelle ressource Ajout de données aux ressources = mise à jour des ressources existantes

En fait, il ne semble pas y avoir de réponse claire. Cependant, les directives suivantes existent en tant que directives de conception.

Il n'y a pas de réponse correcte à cela, mais il y a quelques directives de conception: Lors de la création d'une ressource avec POST, le client ne peut pas spécifier l'URI de la ressource. La décision sur l'URI appartient au serveur. Inversement, lors de la création d'une ressource avec PUT, l'URI de la ressource est déterminée par le client. (Omis) En général, le fait que le client puisse déterminer l'URI d'une ressource signifie que le programmeur qui crée le client est familier avec l'implémentation interne du serveur (quels caractères sont autorisés dans l'URI, quelle est la longueur limite, etc.). Doit être. Par conséquent, PUT a inévitablement une connexion plus étroite avec le serveur. Sauf raison particulière, il est souhaitable de concevoir la ressource à créer par POST et l'URI à décider du côté serveur. [Source: Technologie prenant en charge le Web ── HTTP, URI, HTML et REST]

J'ai également trouvé une telle question lorsque j'ai étudié la différence entre POST et PUT. Le traitement PUT qui ne se met à jour que dans l'API REST est-il approprié?

En tenant compte de ces contenus, POST est utilisé pour créer de nouvelles ressources et PUT est utilisé pour mettre à jour les ressources.

DELETE Lorsque le client supprime une ressource inutile, il envoie une demande DELETE à cet URI. Envoyez et supprimez la ressource.

C'est tout à propos de l'interface unifiée.

Bonus Qu'est-ce que CRUD?

Clad (CRUD) est les quatre principales fonctions requises pour le système. Conditions arrangées de "Créer", "Lire", "Mettre à jour" et "Supprimer"

Parmi les méthodes HTTP, GET, POST, PUT, DELETE satisfont "CRUD"

Bonus Bonus sur les ressources Rails

Dans Rails, vous pouvez écrire comme suit.

config/routes.rb

Sampleapp::Application.routes.draw do
  resources :users
end

Et ce code définit le routage suivant

Il est pratique de pouvoir prendre en charge RESTful uniquement avec ce code.