L'attribut requis doit être un service Web RESTful?

Question

J'espère que ce n'est pas une question stupide mais aujourd'hui j'ai reçu un commentaire disant qu'un service web PHP doit être accessible via une URL conviviale pour être considéré comme RESTful. Est-ce vrai?

Merci!

Answer 1

Bien que pas Wikipedia Restful Information est la fin tout être, mais selon les contraintes définies, une URL conviviale n'est pas l'un d'entre eux.

Le reste style architectural décrit les six contraintes suivantes appliquées à l'architecture, tout en laissant la mise en œuvre des composants individuels libres de concevoir:

client-serveur

Une interface uniforme sépare les clients des serveurs . Cette séparation des préoccupations signifie que, par exemple, les clients ne sont pas concernés par le stockage de données, qui reste interne à chaque serveur, de sorte que la portabilité du code client est améliorée. Les serveurs ne sont pas concernés par l'interface utilisateur ou l'état de l'utilisateur, de sorte que les serveurs peuvent être plus simples et plus évolutifs. Les serveurs et les clients peuvent également être remplacés et développés indépendamment, tant que l'interface entre eux n'est pas altérée.

Stateless

La communication client-serveur est en outre contraint par aucun contexte de client étant stocké sur le serveur entre les requêtes. Chaque requête d'un client contient toutes les informations nécessaires pour traiter la demande, et tout état de session est conservé dans le client. Le serveur peut être en état; cette contrainte exige simplement que l'état côté serveur soit adressable par URL en tant que ressource. Cela permet non seulement de rendre les serveurs plus visibles pour la surveillance, mais également de les rendre plus fiables face à des pannes de réseau partielles, tout en améliorant leur évolutivité.

Cacheable

Comme sur le World Wide Web, les clients peuvent mettre en cache les réponses. Les réponses doivent donc, implicitement ou explicitement, se définir comme pouvant être mises en cache, ou non, pour empêcher les clients de réutiliser des données périmées ou inappropriées en réponse à d'autres demandes. La mise en cache bien gérée élimine partiellement ou complètement certaines interactions client-serveur, améliorant ainsi l'évolutivité et les performances.

système en couches

Un client ne peut pas dire habituellement si elle est directement connecté au serveur final ou à un intermédiaire le long du chemin. Les serveurs intermédiaires peuvent améliorer l'évolutivité du système en permettant l'équilibrage de la charge et en fournissant des caches partagés. Ils peuvent également appliquer des politiques de sécurité.

code

sur demande (en option)

Les serveurs sont temporairement en mesure d'étendre ou de personnaliser les fonctionnalités d'un client par le transfert de code exécutable. Des exemples de cela peuvent inclure des composants compilés tels que des applets Java et des scripts côté client tels que JavaScript.

interface uniforme

L'interface uniforme entre les clients et les serveurs, discutées ci-dessous, et découple simplifie l'architecture, ce qui permet à chaque partie d'évoluer de façon indépendante. Les quatre principes directeurs de cette interface sont détaillés ci-dessous.

La seule contrainte facultative de l'architecture REST est le code à la demande.Si un service viole toute autre contrainte, il ne peut pas strictement être considéré comme RESTful. Le respect de ces contraintes, et donc la conformité au style architectural REST, permettra à tout type de système hypermédia distribué d'avoir des propriétés émergentes souhaitables, telles que la performance, l'évolutivité, la simplicité, la modifiabilité, la visibilité, la portabilité et la fiabilité.

Answer 2

Un URL facile à utiliser n'est pas clairement défini, donc il ne peut pas y avoir une telle contrainte. Facile à utiliser dépend de l'utilisateur. Il n'y a pas de contrainte, HTTP est RESTful et il y a beaucoup d'URL non "conviviales".