Buscar..


Información básica sobre la negociación de contenido de la API de ASP.NET

La negociación de contenido se puede definir como el proceso de selección de la mejor representación para un recurso determinado. Por lo tanto, la negociación de contenido significa que el cliente y el servidor pueden negociar entre ellos para que el cliente pueda obtener datos de acuerdo con el formato requerido.

Hay tres puntos de los que depende internet,

  • El recurso
  • Un puntero a recurso (URL)
  • Representación del recurso.

El tercer punto es más importante que los otros dos, porque todo funciona sobre la base de cómo podemos ver el recurso. Podemos representar un recurso en dos formatos.

  1. Formato XML (lenguaje de marcado extensible)
  2. Formato JSON (Notación de Objetos JavaScript)

Uno de los estándares del servicio RESTful es que el cliente debe tener la capacidad de decidir en qué formato desea la respuesta, ya sea en JSON o XML. Una solicitud que se envía al servidor incluye un encabezado Aceptar. Usando el encabezado Aceptar, el cliente puede especificar el formato para la respuesta.

Por ejemplo,

Accept: application/xml devuelve el resultado en formato XML

Accept: application/json devuelve el resultado en formato JSON

Dependiendo del valor del encabezado Aceptar en la solicitud, el servidor envía la respuesta. Esto se llama Negociación de Contenido.

¿Qué sucede detrás de escena cuando solicitamos datos en un formato específico?

El controlador de la API web de ASP.NET genera los datos que queremos enviar al cliente y entrega los datos a la canalización de la API web que luego busca el encabezado Aceptar del cliente. Luego, elija un formateador apropiado para formatear los datos.

Como la API web de ASP.NET es muy extensible, también podemos especificar varios valores para el encabezado de aceptación en el encabezado de la solicitud.

Accept: application/xml,application/json

En el caso anterior, el servidor elige el primer formateador para formatear los datos de respuesta.

También podemos especificar el factor de calidad en el encabezado de aceptación. En este caso, el servidor elige un formato que tenga mayor factor de calidad.

Accept: application/json;q=0.8,application/xml;q=0.5

Si no especificamos ningún encabezado Aceptar, entonces, por defecto, el servidor elige el formateador JSON.

Cuando la respuesta se envía al cliente en el formato solicitado, observe que el encabezado Content-Type de la respuesta se establece en el valor apropiado. Por ejemplo, si el cliente ha solicitado una application/xml , el servidor envía los datos en formato XML y también establece Content-Type=application/xml .

El servidor utiliza los formateadores para los mensajes de solicitud y respuesta. Cuando el cliente envía una solicitud al servidor, configuramos el encabezado Content-Type al valor apropiado para que el servidor conozca el formato de los datos que estamos enviando.

Por ejemplo, si el cliente está enviando datos JSON, el encabezado Content-Type se establece en application/json . El servidor sabe que está tratando con datos JSON, por lo que utiliza el formateador JSON para convertir los datos JSON al tipo .NET. De manera similar, cuando se envía una respuesta desde el servidor al cliente, según el valor del encabezado Aceptar, se utiliza el formateador adecuado para convertir el tipo .NET a JSON, XML, etc.

Ejemplo de diferentes tipos de formato de respuesta:

aplicación / json:

{
  "Email": "sample string 1",
  "HasRegistered": true,
  "LoginProvider": "sample string 3"
}

aplicación / xml:

<UserInfoViewModel xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/WebApiDemo.Models">
  <Email>sample string 1</Email>
  <HasRegistered>true</HasRegistered>
  <LoginProvider>sample string 3</LoginProvider>
</UserInfoViewModel>

Las aplicaciones web modernas pueden proporcionar datos en varios idiomas y formatos. Entonces, si desarrollamos nuestra API para cubrir usuarios globales en todo el mundo, entonces la negociación de contenido es relevante.

Negociación de contenido en la API web

Entendiendo el concepto

Para comprender la negociación de contenido en la API web, es importante entender el término Resource .

En la web, cualquier información a la que podamos acceder puede ser referida como HTTP resource . Hay una gran cantidad de material para ver en la web que tiene diferentes tipos de contenido, como documentos html, imágenes, video, audio, archivos ejecutables, hojas de cálculo, etc. Podemos obtener cualquier recurso al realizar una solicitud http al uri de recursos. La respuesta http para la solicitud, devuelve el recurso y también especifica el tipo de contenido, que also known as media type .

Para acceder a cualquier recurso, el cliente puede realizar una solicitud de http al proporcionar uri de recursos específicos y los verbos de http. Sin embargo, además de esto, el cliente también puede especificar el tipo de aceptación que es el formato del contenido que el usuario está buscando. El "tipo de aceptación" se puede definir en los encabezados de solicitud http como el encabezado “accept” .

El servidor luego verifica el encabezado de "aceptar" de las solicitudes y devuelve la respuesta en el formato especificado, si está disponible. Tenga en cuenta que el servidor solo puede devolver la respuesta en la representación solicitada si está disponible . Si la representación solicitada no está disponible, devuelve el recurso en la representación predeterminada. Esa es la razón por la que se llama negociación de contenido.


Un ejemplo practico

Como ejemplo, suponga que está realizando una solicitud a http://example.com/customer/1 para obtener la información del cliente con el ID 1. Si no especifica el encabezado “aceptar” en la solicitud, El servidor devolverá la representación predeterminada de este recurso.

Supongamos que el servidor puede devolver la información del cliente en json and xml both . Ahora, está en el cliente especificar el formato requerido de la información del cliente en el encabezado "aceptar" en la solicitud. El valor del encabezado “accept” puede ser “application/json” para la representación json, o “text/xml” para la representación xml. El servidor devolverá la respuesta según el formato solicitado.

Si el formato solicitado es "text / html" que no es compatible con este host (como en este ejemplo), simply return the resource in the default format . La respuesta http contiene un encabezado “content-type” que le informa al cliente sobre el formato del recurso.

Tenga en cuenta que incluso en el caso de que la representación solicitada del recurso no esté disponible, la representación predeterminada del recurso aún se devuelve.

Es por eso que se conoce como negociación de contenidos .

El cliente negocia la representación de la respuesta, sin embargo, si no está disponible, obtiene la predeterminada.


Cómo configurar en la API web

En Web API, la negociación de contenido se puede configurar en la clase WebAPIConfig como

config.Formatters.JsonFormatter.SupportedMediaTypes.Add(new System.Net.Http.Headers.MediaTypeHeaderValue("text/html"));

También puede anular la negociación de contenido predeterminada en la API web mediante la implementación de la interfaz IContentNegotiator y su método de negociación, y luego configurar esto en la línea de solicitud de la API web, en el archivo WebAPI.config como se muestra a continuación:

GlobalConfiguration.Configuration.Services.Replace(typeof(IContentNegotiator), new CustomContentNegotiator());

A continuación se muestra un ejemplo de método de negociación.

public class CustomContentNegotiator : DefaultContentNegotiator
    {
        public override ContentNegotiationResult Negotiate(Type type, HttpRequestMessage request, IEnumerable<MediaTypeFormatter> formatters)
        {
            var result = new ContentNegotiationResult(new JsonMediaTypeFormatter(), new MediaTypeHeaderValue("application/json"));
            return result;
        }


Modified text is an extract of the original Stack Overflow Documentation
Licenciado bajo CC BY-SA 3.0
No afiliado a Stack Overflow