Est-ce que le modèle de service Astoria prend uniquement en charge
ATOM, JSON, XML, XML+HTTP
Les formats comme SOAP, WSDL, ASMX sont-ils obsolètes? Donc lorsque je veux développer une architecture orientée services, puis-je ignorer les formats SOAP, ASMX, WSDL?
Je voudrais ajouter à la réponse ci-dessus et dire qu'il existe en fait un moyen de découvrir les métadonnées concernant le point de terminaison des Services de données (REST). Chaque point de terminaison inclut un document de service (il suffit de faire un GET sur la racine du point de terminaison) qui décrit les ensembles exposés par le service. De plus, en allant au point de terminaison $metadata depuis la racine du service (c'est-à-dire http://mydomain/myservice.svc/$metadata) renvoie un document de métadonnées XML qui décrit entièrement le service (les ensembles, les types, les propriétés sur les types, les relations entre les ensembles et les opérations de service).
Non, absolument pas!
ASMX = services web ASP.NET - c'est obsolète, il a été introduit dans .NET 1.0 et a été essentiellement remplacé par WCF dans .NET 3.0.
MAIS: WCF n'est certainement pas obsolète! WCF est la manière standard de Microsoft de communiquer entre deux systèmes. Il utilise SOAP (y compris WSDL et XSD) par défaut, et c'est une technologie mature et fiable qui fonctionne bien dans des scénarios d'entreprise où vous avez besoin de choses comme l'intégrité des données, la description du service (lisible par l'homme et la machine) via WSDL et les métadonnées du service, et ainsi de suite. SOAP offre également des fonctionnalités plus avancées comme la messagerie fiable et le support transactionnel.
REST / Services de données ADO.NET est une approche plus légère et plus facile d'accès pour exposer des services, mais elle présente de nombreuses lacunes : il n'y a pas de description de service unifiée disponible, donc vous ne pouvez pas vraiment "découvrir" quels méthodes et quels types de données le service offre; soit vous avez connaissance vous-même, soit le fournisseur de services vous donne une documentation en anglais clair, mais il n'y a pas de manière standard de décrire un service REST au monde extérieur (pour l'instant). De plus, vous ne savez pas vraiment à l'avance quel type de données ce service pourrait renvoyer - il n'y a pas de schéma XML à suivre - c'est plus une approche du type "allons frapper le service et voyons ce qui revient" qui peut fonctionner assez bien dans certains cas, mais pas vraiment dans des environnements à plus grande échelle, de type entreprise.
En résumé : le débat SOAP (WSDL, XSD) vs REST est en cours, les deux ont leurs raisons d'être, et je ne vois pas l'un remplacer l'autre - ils se supplantent mutuellement.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
