Estación de servicio

Introducción A servicios RESTful con WCF

Jon Flanders

Descarga de código de la Galería de código de MSDN
Examinar el código en línea

Contenido

Aprendizaje REST
Un ejemplo de resumen
¿Por qué debe se importa sobre REST?
WCF y REST
WebGetAttribute y WebInvokeAttribute
UriTemplate y UriTemplateTable
WebHttpBinding y WebHttpBehavior
WebServiceHost y WebServiceHostFactory
Utilizar el código de ejemplo

Éste es el primero en una serie de columnas sobre la creación de servicios de Windows Communication Foundation (WCF) mediante el estilo de arquitectura conocido como Representational estado transferencia (REST). Podría decir que 2009 será el año de REST aquí en la columna de la estación de servicio, y es largo vencida en mi opinión. REST ha sido un estilo popular durante muchos años desde su presentación en 2000.

En esta primera columna, desea describa algunas de los principios básicos de REST, así como presenta una implementación de un servicio RESTful mediante WCF. En el futuro las columnas, le cavar en más detalles de las ideas base de REST, así como las tecnologías que se basan en esa base.

Aprendizaje REST

Un estilo de arquitectura es un conjunto de restricciones que se pueden aplicar al crear algo. Y un estilo de arquitectura de software es algo que se describen las características que pueden utilizarse para guiar la implementación de un sistema de software. REST es un estilo de arquitectura que se puede utilizar para crear software en el que los clientes (agentes de usuario) pueden efectuar peticiones de servicios (extremos). REST es una forma implementar un estilo de arquitectura de cliente / servidor, de hecho, REST explícitamente se basa en el estilo de arquitectura de cliente / servidor.

Un hombre denominado Roy Thomas Fielding acuñó primero el término REST como un concepto en su (de disertación PhD "Estilos de arquitectura y el diseño de arquitecturas de software en función de red "). Era uno de las personas que trabajaron en la especificación que conduce la mayor parte de Internet de hoy: Protocolo de transferencia de hipertexto (HTTP). Normalmente el fondo de las personas que describen un estilo de arquitectura no es relevante para una explicación del estilo, pero aquí CREO que es importante porque CREO que una de las mejores maneras de obtener una comprensión básica de REST consiste en pensar en el Web y cómo funciona.

Tiene a suponer, como desarrollador, está familiarizado con (y, como yo, probablemente un gruesa diario addict o usuario de) el Web. Posiblemente, la Web puede se considera como el más grande, más escalable y más populares distribuyen aplicación de todo el tiempo. Las restricciones del REST se basan en los mismos principios subyacentes que rigen el Web. Estos principios son:

• Los agentes de usuario interactúan con los recursos, y los recursos son todo lo que puede denominado y representado. Cada recurso se puede solucionar a través de una única (URI).
• Interacción con los recursos (ubicado a través de su URI único) se realiza mediante una interfaz uniforme de los verbos estándar de HTTP (GET, POST, PUT y DELETE). También importante en la interacción es la declaración del tipo de medio del recurso, que es designado mediante el encabezado HTTP Content-Type. (XHTML, XML, JPG, PNG y JSON son algunos tipos de medios conocidos).
• Los recursos son autodescriptiva. Toda la información necesaria procesar una solicitud de un recurso está dentro de la misma solicitud (que permite servicios para ser sin estado).
• Los recursos contienen vínculos a otros recursos (hipervolúmenes multimedia).

Un ejemplo de resumen

Un servicio que utilice la arquitectura de REST generalmente se conoce como un servicio RESTful o extremo. Sólo para obtener una sensación de las ideas detrás de este estilo de arquitectura, voy a presentar un ejemplo más pequeño. Imagine necesarios para crear un servicio para trabajar con los datos detrás MSDN Magazine: se ha publicado un servicio que podría decirme todos los años MSDN Magazine y cada uno de los artículos de cada problema. Supongamos que el requisito es que los editores de la revista puede utilizar este servicio para agregar artículos nuevos y administrar los datos de próximos problemas.

Al crear servicios RESTful, puede ir a un conjunto muy simple de pasos básicos para diseñar su servicio:

1. ¿Qué se van los recursos a?
2. ¿Cuáles son los identificadores URI que se va a utilizarse para representar los recursos?
3. ¿Qué partes de la interfaz uniforme (verbos HTTP) cada identificador URI va a admitir?

Estos son los bloques básicos de creación de un extremo RESTful: recursos y sus representaciones, los identificadores URI para los recursos y las partes de la interfaz uniforme a los que responderá cada identificador URI. Son más avanzados características puede aprovechar las ventajas de, como uso de códigos de estado más explícitas y utilizar hipervínculos para administrar el estado del recurso, pero en este ejemplo voy a cumplir los conceptos básicos.

Ahora pueden usar estos pasos para diseñar mi servicio hipotética. Los recursos son todas de los años que MSDN Magazine ha publicado, todos los problemas publicados cada año, y todos los artículos publican en cada revista. Fines de este ejemplo concreto, me va que usar una aplicación multimedia de tipo y xml (XML) para representar estos recursos, pero es importante recordar que RESTful servicios no son de ninguna forma limitada a XML como tipo de los medios.

A continuación, debe determinar los identificadores URI para cada recurso. Derecha ahora sólo necesita determinar los identificadores URI relativos puesto que el identificador URI absoluto vendrá determinado por dónde se el extremo de host. La lista de años estará la raíz del identificador URI del servicio (/). Con esta sintaxis, / {año} devolverá todos los problemas para cada año; o {año} / {problema} será el URI para cada problema (será identificar cada problema por el mes de publicación); y / {año} / {emitir} / {artículo} representará cada artículo (he supuesto cada artículo se numeran de 1 a n en cada problema).

A continuación se incluye la asignación de identificadores URI a la interfaz uniforme. Dado que el historial de la revista realmente debe ser de sólo lectura, el recurso raíz expone sólo GET. Se pueden agregar un nuevo año siguiendo un PUT al identificador URI y {año}. PUT se utiliza para crear nuevos recursos en el cuando se conoce el identificador URI del nuevo recurso por el cliente, en el como podría ser en este caso. PUT también se puede utilizar para actualizar los recursos existentes cuando se conoce el identificador URI. POST se utiliza para crear un recurso cuando no se conoce el identificador URI del nuevo recurso por el cliente, por lo que POST será el verbo VOY a utilizar cuando se agrega un nuevo recurso de artículo, que debe enviarse a la o {año} / {emitir} identificador URI.

Puede ir con cada recurso y cada verbo, pero espero que ha llegado un funcionamiento para los pasos que se vaya a través a determinar el diseño de un extremo RESTful. Puede ver la lista completa de recursos, los identificadores URI y verbos en la figura 1 .

Si desea consumir los artículos de enero de 2006 como un cliente, desea realizar un HTTP GET y enero de 2006. Si fueron el editor y desea agregar un artículo a diciembre de 2008, el cliente podría POST un recurso del artículo a y Diciembre de 2008 y un nuevo artículo podría agregarse a ese problema. Éste es el modelo que podría seguir utilizando una y otra vez para poder consumir este servicio como un cliente.

¿Por qué debe se importa sobre REST?

Por lo que ahora que ha explicado un poco sobre REST, es probablemente pregunte por qué debe cuidado. Como desarrollador, deberá motivación para aprender y adoptar cualquier estilo, tecnología o patrón. Si se está leyendo esta revista, es probable que un programador en la pila de tecnología de Microsoft. Y para implementar aplicaciones cliente de servidor, es probable que ha usado otro estilo arquitectura: llamada a procedimiento remoto (RPC). Si utiliza propietarios sistemas RPC, como DCOM o .NET Remoting o usado tecnologías de RPC interoperables, como SOAP usan ASMX o WCF, son las implementaciones del estilo cliente-servidor que hemos tenido en la plataforma de Microsoft. Por lo que ¿por qué Obtenga información acerca de o utilizar REST?

En mi mente, hay dos razones principales. En primer lugar, REST ofrece algunas funciones importantes y las ventajas sobre tecnologías RPC en muchos casos. En segundo lugar, Microsoft está trasladando muchas de sus propias implementaciones fuera de tecnologías RPC (como SOAP) y hacia REST. Esto significa que incluso si no está convencido o motivados para utilizar REST para crear sus propios sistemas, como más marcos de trabajo y las tecnologías de Microsoft (y otros) mover a REST, bien deberá saber cómo interactuar con ellos.

Las siguientes es una lista de otras ventajas (pero no considere esta lista exhaustiva):

almacenamiento en caché Cuando se le pregunte RESTful extremos para los datos mediante HTTP, el verbo HTTP utilizado es GET. Devuelto en respuesta a una solicitud GET de recursos pueden almacenar en caché de muchas maneras diferentes. GET condicional, que es una manera que un cliente puede comprobar con el servicio si su versión de los datos es todavía la versión actual, es un detalle de implementación opcional puede implementar un extremo RESTful que puede mejorar aún más velocidad y la escalabilidad.

salida de escala REST anima a cada recurso para que contenga todos los estados necesarios para procesar una solicitud determinada. Servicios rESTful son mucho más fáciles de escalado horizontal cuando éstos cumplir esta restricción y pueden ser sin estado.

Efectos secundarios Servicios rESTful no deben tener efectos secundarios cuando se solicita un recurso utilizando GET (Desgraciadamente, esta restricción es más fácil romper que algunas de las otras restricciones REST.

inalterable Los otros dos principales HTTP verbos utilizados normalmente como parte de la interfaz uniforme se PUT y DELETE. PUT se suele utiliza cuando un agente de usuario desea modificar un recurso y DELETE es autodescriptiva. El bit importante (y lo que describen el inalterables palabra) es que puede utilizar estos dos verbos más de una vez en un recurso determinado, y el efecto será el mismo que la primera vez que utiliza los, o al menos no haya ningún efecto adicional. Esto es tranquilizador al generar sistemas confiables distribuidos en los errores, errores de red, o latencia podría producir código para ejecutar varias veces.

interoperabilidad Muchas personas tout SOAP como el método más interoperable para implementar programas cliente de servidor. Pero algunos lenguajes y entornos aún no tienen kits de herramientas SOAP. Y algunas que tienen los kits de herramientas se basan en estándares anteriores que siempre no pueden comunicarse con kits de herramientas que implementan los estándares más recientes. REST sólo requiere una biblioteca HTTP que estén disponibles para casi todas las operaciones (una biblioteca XML, of course, suele ser útil as well), y es sin duda más interoperable que cualquier tecnología RCP (incluyendo SOAP).

simplificar Esta ventaja es más subjetiva de los demás y puede suponer cosas distintas a diferentes personas. A mí, la sencillez de uso REST está relacionada con los identificadores URI que representa los recursos y la interfaz uniforme. Como un surfer Web realizado, comprender escribir identificadores URI diferente en mi explorador para obtener distintos recursos (esto a veces se conoce como identificador URI o dirección URL de piratería, pero no es malvado en modo alguno). Causa de esta experiencia en mediante los URI para muchos años, diseñar los URI para recursos parece muy natural a mí. Mediante la interfaz uniforme simplifica el desarrollo por me liberación de tener que crear una interfaz, contrato o API para cada servicio que se necesita para crear. La interfaz (cómo los clientes interactuará con mi servicio) se establece mediante las restricciones de la arquitectura.

Como dicho, esto no es una lista exhaustiva ni debe hacerlo como evidencia conclusive que REST es la tecnología sólo es true para utilizar siempre. Debe tener en cuenta de las ventajas por lo que puede aprovechar ellos cuando sea apropiado.

WCF y REST

WCF es el marco de Microsoft para crear aplicaciones que se comunican a través de una red, con independencia del protocolo o estilo. El concepto de WCF consistía en crear un marco que estaba extensibles y conectables para que pueda Obtenga información acerca de un modelo de programación y la configuración y se puedan aplicar esos conocimientos a numerosos tipos diferentes de sistemas distribuidos a los desarrolladores.

Aunque es verdad que gran parte de WCF está orientado a RPC (mediante SOAP), realmente ha tenido la posibilidad de exponer y consumir servicios REST ya que en primer lugar se lanzó como parte de .NET Framework 3.0. ¿Qué falta era un modelo de programación necesario para hacer uso REST con WCF fácil. También había algunas partes de la infraestructura que tenía que crear para realizar REST trabajar con .NET Framework 3.0. WCF en .NET Framework 3.5 en el ensamblado System.ServiceModel.Web se han agregado un modelo de programación y los fragmentos de infraestructura. Y .NET Framework 3.5 SP1 agrega unas pequeñas mejoras así.

El modelo de programación centra alrededor de dos nuevos atributos, WebGetAttribute y WebInvokeAttribute y un mecanismo de plantilla de identificador URI que permite a declarar el identificador URI y el verbo a la que cada método se va a responder. La infraestructura se incluye en forma de un enlace (WebHttpBinding) y un comportamiento (WebHttp­Behavior) que proporcionan la pila de red correcta para utilizar REST. Además, hay algunos ayuda de infraestructura de alojamiento de un Service­Host personalizado (WebServiceHost) y un ServiceHostFactory (WebServiceHostFactory).

WebGetAttribute y WebInvokeAttribute

Una de las formas que WCF simplifica la creación de sistemas conectados es enrutar mensajes de red a los métodos en instancias de las clases que defina como las implementaciones de su servicio. Esto permite concentrarse en la lógica del código en los servicios en lugar de la infraestructura necesaria procesar el tráfico de red.

De forma predeterminada, WCF hace esta ruta (también conocido como distribución) según el concepto de acción. Para esta distribución para trabajar, una acción debe estar presentes en cada mensaje que recibe de WCF en su nombre. Cada acción única se asigna a un método de acción concreto.

El valor de acción se basa en el nombre de su método (y el espacio de nombres del servicio de) o un valor personalizado (establecer a través de la propiedad OperationContractAttribute.Action). Este sistema de distribución está estrechamente emparejada para SOAP como encabezado de acción de la especificación SOAP se utiliza de forma predeterminada. Afortunadamente, al igual que casi todo lo más en WCF, este predeterminado distribuir la infraestructura es reemplazable.

Cuando se utiliza la infraestructura REST con WCF, el distribuidor predeterminada se sustituye por uno que las rutas según no acción, pero en su lugar se basa en el identificador URI de la solicitud entrante y el verbo HTTP usado. Esta ruta (realizado por una clase denominada WebHttpDispatchOperationSelector) permite implementar fácilmente un extremo RESTful. Este distribuidor está configurado en cada extremo un comportamiento denominado WebHttpBehavior, que debe ser agregado a cada extremo de la que desea utilizar este modelo de programación (aunque es a menudo no tenga que hacerlo manualmente, como se verá más adelante).

La clave para realizar este trabajo es para que el WebHttpDispatch­OperationSelector saber cómo asignar diferentes verbos y los identificadores URI a los métodos. Para ello, el WebGetAttribute y WebInvokeAttribute deben agregarse a los métodos en el tipo de WCF ServiceContract.

WebGetAttribute indica el distribuidor que el método debe responder a solicitudes HTTP GET. WebInvokeAttribute está asignado a POST de HTTP de forma predeterminada, pero la propiedad WebInvokeAttribute.Method puede establecerse para permitir que cualquiera de los otros verbos HTTP (PUT y DELETE que se va a los dos más común). De forma predeterminada, el identificador URI viene determinado por el nombre del método (agregado en el identificador URI base del extremo).

Esto no es realmente muy RESTful, ya que los nombres de método no lo que desea tratar de REST porque representan verbos. ¿Qué desea exponer como identificadores URI son los nombres. Por esta razón, el modelo de programación de WCF REST permite la personalización de URI para cada método mediante plantillas que pueden establecerse a través de la propiedad UriTemplate en WebGetAttribute o WebInvokeAttribute.

UriTemplate y UriTemplateTable

Para habilitar la personalización del URI para cada método y el verbo de combinación de WCF, agrega la capacidad de definir el URI para cada recurso mediante una sintaxis especial de plantilla, como la que utiliza anteriormente en esta columna para describir el extremo de servicio MSDN Magazine. Esta sintaxis permite definir con reemplazable símbolos (tokens), la estructura del identificador URI que desea que cada método para representar en combinación con el verbo HTTP (mediante el WebGetAttribute o WebInvokeAttribute). Obtendrá en la sintaxis con más detalle en una columna futura.

la figura 2 muestra la definición de WCF ServiceContract para el servicio MSDN Magazine (con los atributos correspondientes y personalizaciones UriTemplate) y aplica las características que he mencionado anteriormente. Extiende el sistema de definición de contrato WCF existente con el WebGetAttribute para aquellas operaciones que debe responder a GET. También agrega WebInvokeAttribute a la operación para responder a los otros verbos.

La Figura 2 WCF ServiceContract definición

[ServiceContract]
public interface IMSDNMagazineService
{
    [OperationContract]
    [WebGet(UriTemplate="/")]
    IssuesCollection GetAllIssues();
    [OperationContract]
    [WebGet(UriTemplate = "/{year}")]
    IssuesData GetIssuesByYear(string year);
    [OperationContract]
    [WebGet(UriTemplate = "/{year}/{issue}")]
    Articles GetIssue(string year, string issue);
    [OperationContract]
    [WebGet(UriTemplate = "/{year}/{issue}/{article}")]
    Article GetArticle(string year, string issue, string article);
    [OperationContract]
    [WebInvoke(UriTemplate = "/{year}/{issue}",Method="POST")]
    Article AddArticle(string year, string issue, Article article);

}

En este caso, en el método AddArticle agrega (método) = "POST" para facilitar su lectura, como el verbo predeterminado de WebInvokeAttribute es POST. Tanto los métodos GET y POST tienen personalización de identificador URI mediante el atributo UriTemplate. Observe que la sintaxis UriTemplate permite varios segmentos de ruta de acceso variable y que cada uno de los segmentos de ruta de acceso se pasan a los métodos como argumentos.

WebHttpBinding y WebHttpBehavior

En WCF, un enlace determina cómo WCF va a comunicar. Un enlace es realmente la configuración que indica cómo crear lo que se conoce como la pila de canales, que es el conjunto de objetos que se funcionan conjuntamente para proporcionar el tipo de comunicación que desee para un extremo específico de WCF.

Para un extremo RESTful, el enlace que utiliza es WebHttpBinding. A diferencia de muchos otros enlaces, WebHttpBinding es bastante sencilla, que contiene sólo dos componentes: el transporte HTTP y el codificador de mensajes de texto (establecida en No espera o utilizar SOAP, XML sin formato sólo).

Como mencioné anteriormente, WebHttpBehavior es el objeto que hace que el distribuidor de identificador URI de más de verbo que se va a utilizar, por lo que la WebHttpBinding y la WebHttpBehavior son casi siempre utiliza conjuntamente. Aquí es el código para crear un extremo tal si se autoalojamiento un extremo RESTful de WCF:

ServiceHost sh = 
  new ServiceHost(typeof(MSDNMagazineServiceType));
string baseUri = "http://localhost/MagazineService";
ServiceEndpoint se = 
  sh.AddServiceEndpoint(typeof(IMSDNMagazineService),
  new WebHttpBinding(), baseUri);
se.Behaviors.Add(new WebHttpBehavior());
sh.Open();

Observe que no sólo ¿tengo que especificadas el WebHttpBinding al agregar el extremo final a ServiceHost, también debe agregar explícitamente el WebHttpBehavior al extremo para hacer que funcione el sistema de distribución de identificador URI de más de verbo. Por supuesto, puede hacer esto con configuración así (consulte la figura 3 ).

Figura 3 identificador URI de más de verbo y distribución en la configuración

<configuration>
  <system.serviceModel>
    <services>
      <service name="MSDNMagazine.MSDNMagazineServiceType">
        <endpoint 
          address="http://localhost/MagazineService" 
          binding="webHttpBinding" 
          contract="MSDNMagazine.IMSDNMagazineService" 
          behaviorConfiguration="webby"/>
      </service>
    </services>
    <behaviors>
      <endpointBehaviors>
        <behavior name="webby">
          <webHttp/>
        </behavior>
      </endpointBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

WebServiceHost y WebServiceHostFactory

Una de las quejas acerca de WCF es que en ocasiones, es demasiado complejo, especialmente en términos de configuración. Para aliviar este problema con extremos RESTful (de nuevo, simplicidad es una de las ventajas se indicó oft de REST), Microsoft agregado dos nuevos tipos, WebServiceHost y WebServiceHostFactory, a .NET Framework 3.5.

WebServiceHost es un tipo derivado de ServiceHost, lo que simplifica los escenarios de autoalojamiento de extremos RESTful. El código para autohospeda con WebServiceHost es similar al siguiente:

string baseUri = "http://localhost/MagazineService";
WebServiceHost sh = 
  new WebServiceHost(typeof(MSDNMagazineServiceType),
  new Uri(baseUri));
sh.Open();

Éste es una optimización interesante, ya que evita el código repetitivo de agregar WebHttpBinding y WebHttpBehavior manualmente. La clase WebServiceHost automáticamente crea el extremo final y configura con el WebHttpBinding y WebHttpBehavior.

En el escenario de hospedaje administrado con WCF, dentro de Internet Information Services (IIS), WCF requiere normalmente un archivo .svc que señale a la tipo de servicio, más entradas en el archivo web.config para informar a WCF sobre el extremo (el enlace y comportamientos entre otra configuración).

Para simplificar el escenario de hospedaje administrado, Microsoft agregado WebServiceHostFactory, que utiliza un punto de extensibilidad WCF abierto (utilizando un tipo ServiceHostFactory personalizado) en el escenario hospedaje administrado crear una experiencia de libre de configuración para numerosos servicios RESTful. El archivo .svc tendrá este aspecto:

<%@ ServiceHost Factory=
  "System.ServiceModel.Activation.WebServiceHostFactory"   
  Service="MSDNMagazine.MSDNMagazineServiceType" %>

WebServiceHostFactory crea una instancia de la WebServiceHost y puesto que la WebServiceHost automáticamente configurar el extremo con WebHttpBinding y WebHttpBehavior, hay no es necesario que cualquier configuración de este extremo en el archivo web.config en todos los. (Por supuesto, si desea personalizar el enlace, debe utilizar el sistema de configuración o cree una clase que deriva de WebServiceHost/WebServiceFactory). Si necesito personalizar el enlace, todavía puede agregar las entradas adecuadas en el archivo configuración. la figura 4 muestra un archivo de configuración que debe activar la autenticación básica HTTP en el extremo de servicio.

La figura 4 activar autenticación básica HTTP

<configuration>
<system.serviceModel>
  <services>
    <service name="MSDNMagazine.MSDNMagazineServiceType">
      <endpoint 
        address="http://localhost/MagazineService" 
        binding="webHttpBinding" 
        contract="MSDNMagazine.IMSDNMagazineService" 
        behaviorConfiguration="webby"/>
    </service>
  </services>
  <bindings>
    <webHttpBinding>
      <binding name="secure">
        <security mode="Transport">
          <transport clientCredentialType="Basic"/>
        </security>
      </binding>
    </webHttpBinding>
  </bindings>
  <behaviors>
    <endpointBehaviors>
      <behavior name="webby">
        <webHttp/>
      </behavior>
    </endpointBehaviors>
  </behaviors>
</system.serviceModel>
</configuration>

Utilizar el código de ejemplo

Mediante la explicación de las características de WCF en relación con REST, ha disponen la mayor parte de la implementación del servicio que propuesto al principio de la columna de. Permítanme recorra interactuar con este servicio.

Una vez que tenga el servicio de seguridad y en ejecución, puede aciertos su raíz URI con cualquier cliente, incluido un explorador Web tal Internet Explorer. Ser capaz de ejecutar pruebas rápidas RESTful extremos con un explorador es, se acepta la mayor parte, una muy útil consecuencia del estilo de arquitectura REST basarse en el modo de funcionamiento de la Web. Puede ver el resultado en la figura 5 .

La figura 5 identificador URI de recurso de raíz

En este caso, me aloja en Visual Studio 2008 Web desarrollo Server, que determina el identificador URI base. El archivo de Issues.svc es el archivo necesario de WCF en el escenario hospedaje administrado. Si desea ver el resultado de un año determinado, sólo PUEDO agregar ese año a la dirección (URI) en el explorador (consulte la figura 6 ).

Figura 6 el recurso de representación del año 2007

Si le pregunte para octubre de 2008, el identificador URI sería localhost:1355/Issues.svc/2008/october, que, en este momento, podría ser un conjunto vacío. Y si desea agregar un artículo, podría hacer un HTTP POST a ese identificador URI con la representación XML de un artículo como el cuerpo de la solicitud HTTP.

Otra característica interesante de HTTP es todas las herramientas que están disponibles para interactuar con él. Uno de mis favoritos es Fiddler , que permite espía de solicitudes HTTP y las respuestas. Pero también tiene una característica que permite me realizar operaciones de HTTP arbitrarias. Por lo que puede utilizar la ficha de generador de solicitudes de Fiddler para realizar mi POST de HTTP (consulte la figura 7 ). Puede ver una solicitud del recurso de octubre de 2008 después la POST en la figura 8 .

La figura 7 cómo hacer que un HTTP POST solicitud para crear un nuevo recurso de artículo con Fiddler

Figura 8 agregada recursos de artículo

Aunque se puede argumentar que Internet Explorer y Fiddler son clientes reales, creación de una implementación real de cliente / servidor es una extensión de estos pasos simples que sólo fue (un ejemplo más complejo de creación de que un cliente RESTful vendrá en una columna de una versión posterior). Un cliente necesita conocer el identificador URI de cada recurso y qué partes de la interfaz uniforme a utilizar con cada identificador URI. A continuación, el cliente puede interactuar con el servicio mediante el uso estas piezas de información para crear su funcionalidad.

Lo que he mostrado en esta primera columna es el conjunto base de características WCF que habilitar el estilo de la arquitectura REST para utilizarse en las aplicaciones .NET con facilidad. Esta base permite otras tecnologías interesantes, incluidas cosas tales como las fuentes Web (RSS y Atom) y compatibilidad con recursos de JSON codificada para la interacción con AJAX.

En las columnas algunas siguiente, voy a esta base conocimientos de REST y WCF y profundizar en los detalles de varias otras características de la plataforma de Microsoft que se basan en este estilo y la tecnología. También se le tratar con algunas de las preguntas más frecuentes de REST, por ejemplo, sobre seguridad y sobre la idea de implementar los extremos de procesamiento.

Envíe sus preguntas y comentarios a sstation@Microsoft.com .

Tomás Flanders es un consultor independiente, orador y profesor de Pluralsight. Se especializa en BizTalk Server, Windows Workflow Foundation y Windows Communication Foundation. Puede ponerse en contacto con Tomás en masteringbiztalk.com/blogs/Jon .