c# - pudo - ¿Qué causa una diferencia entre una URL de servicio web y un espacio de nombres?
diferencia entre url y dominio de internet (3)
Tengo un proyecto web ASP.NET que contiene un servicio web. Cuando ejecuto el servicio, me lleva a una página que muestra todos los métodos que están expuestos, usando una URL similar a http://api.example.com/game/service.asmx .
En el código para el servicio web hay métodos que tienen los siguientes atributos:
[WebService(Namespace = "http://webservices.example.com/GameServices/Game1")]
[WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
public class Game1 : System.Web.Services.WebService
{
// code
}
Estoy un poco confundido sobre por qué el espacio de nombres en una clase con el atributo webService es diferente a la ruta al servicio web. ¿De dónde viene ese espacio de nombres? ¿Está hecho solo?
El espacio de nombre puede ser cualquier valor que asigne. Creo que se considera una mejor práctica hacer que el espacio de nombres sea el mismo que el URL del servicio.
En resumen, sí, los espacios de nombres están compuestos. Son simplemente una manera de distinguir un documento de otro. Es más común usar una estructura de URL en su espacio de nombres porque estos son típicamente únicos.
Sí, está hecho.
Eso suena tonto, pero es verdad. El espacio de nombres especificado allí, en su código, se usará en los documentos XML que se intercambian como solicitudes y respuestas para ese servicio web en particular. Si coloca un programa de rastreo de red en el cable, verá esas cadenas de espacio de nombres utilizadas en los mensajes hacia adelante y hacia atrás. En los servicios web, su aplicación no necesita preocuparse por el espacio de nombres, por lo general. La biblioteca de servicios web generalmente se encarga de eso.
No se requiere que el espacio de nombres sea una URL HTTP, aunque a menudo las personas usan URL HTTP. Esta puede ser la fuente de la mayor parte de la confusión de su parte. La Recomendación IETF para espacios de nombres XML sugiere que debe ser un URI , pero ese URI no necesita ser un URI HTTP, y de hecho no necesita tener ningún "protocolo de red" adjunto.
El espacio de nombres es ... una cadena. Se usa como una forma simple de calificar información en un esquema XML. Piense en ello como el apellido de una persona. Puede conocer a varias personas llamadas "Chris". Usted los distingue por sus apellidos.
De forma similar, el nombre del elemento "id" se puede usar en muchos documentos y esquemas XML diferentes. Las aplicaciones (y también las personas) pueden distinguir entre los muchos elementos diferentes que usan el qname "id" a través de su espacio de nombres xml.
Normalmente, un "arquitecto de información" especificará el espacio de nombres XML para un documento o un servicio web como un URI que es jerárquico, exclusivo de la organización propietaria y relevante para el significado de la información en el documento XML. (En una organización pequeña, el "arquitecto de información" es solo un desarrollador). Por ejemplo, http://mycompany.com/services/2013/customer podría ser un espacio de nombres para MyCompany, creado en 2013 y perteneciente a servicios, y específicamente al cliente. Servicio.
En mi opinión, no hay una razón real para usar http:// como el esquema en el URI para un espacio de nombres XML, a menos que planee hacer que la documentación esté disponible en ese URI HTTP. También podría usar urn: mycompany.com/services/2013/customer como el espacio de nombres XML. De hecho, podría ser mejor, porque indica que es solo un nombre, no es un localizador. (no una dirección web).
Normalmente utilizo un URN, prefijado con urn: como el esquema, para indicar que el espacio de nombre es simplemente un nombre, un unificador.
EDITAR Hay reglas para la estructura de URNs . El formato básico es:
urna: <NID>: <NSS>
... donde NID es una id de espacio de nombres, uno de un conjunto de cadenas especiales aprobadas y NSS es una cadena específica de espacio de nombre. La lista de NID aprobados incluye isbn, uuid, ietf y alrededor de otros 20, cada uno tiene un significado específico definido por un IETF RFC distinto.
A pesar de las reglas sobre los NID, muchas personas simplemente no se molestan en conformarse y acuñan sus propios URN usando su nombre de dominio en lugar del NID. por ejemplo, "mycompany.com". (Esto es lo que hago, a menudo).
Entonces es su elección cómo quiere calificar más el nombre. Puede especificar "servicios" para indicar un servicio web. Algunas personas usan el año y el mes en que se lanzó el servicio en un espacio de nombres. Esto le permite actualizar el servicio y usar una fecha diferente para distinguir entre diferentes elementos. Un ejemplo de espacio de nombres XML que sigue esta convención de nomenclatura podría ser:
urn:mycompany.com:services:2011:04:Game
Esto es lo que RFC 2141 llama una "URN no válida" porque no usé un NID registrado. Pero sirve mi propósito. Es un simple paso para transformarlo en una "URN válida" aplicando el NID fdc , definido por RFC 4198 .
urn:fdc:mycompany.com:services:2011:04:Game
¿Ves cuánto mejor eso es?
Al final, la mayoría de las personas simplemente establece su propia convención de nomenclatura, algo que tiene sentido para sus usos, para los consumidores internos y socios de los datos XML.