Introduccin A servicios RESTful con

WCF
Jon Flanders
Descarga de cdigo de la Galera de cdigo de MSDN
Examinar el cdigo en lnea
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 cdigo de ejemplo
ste es el primero en una serie de columnas sobre la creacin de servicios de Windows Communication Foundation (WCF)
mediante el estilo de arquitectura conocido como Representational estado transferencia (REST). Podra decir que 2009 ser el
ao de REST aqu en la columna de la estacin de servicio, y es largo vencida en mi opinin. REST ha sido un estilo popular
durante muchos aos desde su presentacin en 2000.
En esta primera columna, voy a hablar de algunos de los principios bsicos de REST y de cmo presentar una implementacin
de un servicio RESTful mediante WCF.En columnas futuras, profundizar en ms detalles de las ideas base de REST, as como en
las tecnologas que se construyen 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 caractersticas que pueden utilizarse para guiar la implementacin 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 explcitamente se basa en el estilo de arquitectura de cliente / servidor.
Un hombre denominado Roy Thomas Fielding acu primero el trmino REST como un concepto en su (de disertacin PhD
"Estilos de arquitectura y el diseo de arquitecturas de software en funcin de red "). Era uno de las personas que trabajaron en
la especificacin 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 explicacin del estilo, pero aqu CREO
que es importante porque CREO que una de las mejores maneras de obtener una comprensin bsica de REST consiste en
pensar en el Web y cmo 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 ms grande, ms escalable y ms populares distribuyen aplicacin 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 interactan con los recursos, y los recursos son todo lo que puede denominado y representado. Cada
recurso se puede solucionar a travs de una nica (URI).
Interaccin con los recursos (ubicado a travs de su URI nico) se realiza mediante una interfaz uniforme de los verbos
estndar de HTTP (GET, POST, PUT y DELETE). Tambin importante en la interaccin es la declaracin 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 informacin necesaria procesar una solicitud de un recurso est dentro de la misma
solicitud (que permite servicios para ser sin estado).
Los recursos contienen vnculos a otros recursos (hipervolmenes multimedia).
Un ejemplo de resumen
Un servicio que utilice la arquitectura de REST generalmente se conoce como un servicio RESTful o extremo. Slo para obtener
una sensacin de las ideas detrs de este estilo de arquitectura, voy a presentar un ejemplo ms pequeo. Imagine necesarios
para crear un servicio para trabajar con los datos detrs MSDN Magazine: se ha publicado un servicio que podra decirme todos
los aos MSDN Magazine y cada uno de los artculos de cada problema. Supongamos que el requisito es que los editores de la
revista puede utilizar este servicio para agregar artculos nuevos y administrar los datos de prximos problemas.
Al crear servicios RESTful, puede ir a un conjunto muy simple de pasos bsicos para disear su servicio:
1. Qu se van los recursos a?
2. Cules 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 bsicos de creacin 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 ms avanzados caractersticas
puede aprovechar las ventajas de, como uso de cdigos de estado ms explcitas y utilizar hipervnculos para administrar el
estado del recurso, pero en este ejemplo voy a cumplir los conceptos bsicos.
Ahora pueden usar estos pasos para disear mi servicio hipottica. Los recursos son todas de los aos que MSDN Magazine ha
publicado, todos los problemas publicados cada ao, y todos los artculos publican en cada revista. Fines de este ejemplo
concreto, me va que usar una aplicacin 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 continuacin, debe determinar los identificadores URI para cada recurso. Derecha ahora slo necesita determinar los
identificadores URI relativos puesto que el identificador URI absoluto vendr determinado por dnde se el extremo de host. La
lista de aos estar la raz del identificador URI del servicio (/). Con esta sintaxis, / {ao}devolver todos los problemas para cada
ao; o {ao}/ {problema}ser el URI para cada problema (ser identificar cada problema por el mes de publicacin); y / {ao}/
{emitir}/ {artculo}representar cada artculo (he supuesto cada artculo se numeran de 1 a n en cada problema).
A continuacin se incluye la asignacin de identificadores URI a la interfaz uniforme. Dado que el historial de la revista
realmente debe ser de slo lectura, el recurso raz expone slo GET. Se pueden agregar un nuevo ao siguiendo un PUT al
identificador URI y {ao}. PUT se utiliza para crear nuevos recursos en el cuando se conoce el identificador URI del nuevo recurso
por el cliente, en el como podra ser en este caso. PUT tambin 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 artculo, que debe enviarse a
la o {ao}/ {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 travs a
determinar el diseo de un extremo RESTful. Puede ver la lista completa de recursos, los identificadores URI y verbos en la
figura 1 .
Soporte de sistema de operativo de la figura 1
Recurso IDENTIFICADOR URI Verbos
Todos los aos "/ " GET
Problemas de un ao
determinado
" / {ao}" GET, PUT
Un problema
determinado
" / {ao}/ {emitir}" GET, PUT
Un artculo
" / {ao}/ {emitir}/
{artculo}"
GET, POST (se asignar el nmero de artculo por el sistema), PUT,
DELETE (eliminar debe estar desactivada una vez que se ha
publicado un problema)
Si desea consumir los artculos de enero de 2006 como un cliente, desea realizar un HTTP GET y enero de 2006. Si fueron el
editor y desea agregar un artculo a diciembre de 2008, el cliente podra POST un recurso del artculo a y Diciembre de 2008 y
un nuevo artculo podra agregarse a ese problema. ste es el modelo que podra 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 motivacin para aprender y adoptar cualquier estilo, tecnologa o patrn. Si se est leyendo esta revista, es probable que
un programador en la pila de tecnologa 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 tecnologas 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 informacin acerca de o utilizar
REST?
En mi mente, hay dos razones principales. En primer lugar, REST ofrece algunas funciones importantes y las ventajas sobre
tecnologas RPC en muchos casos. En segundo lugar, Microsoft est trasladando muchas de sus propias implementaciones fuera
de tecnologas 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 ms marcos de trabajo y las tecnologas de Microsoft (y otros) mover a REST, bien deber
saber cmo 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 versin de los datos es
todava la versin actual, es un detalle de implementacin opcional puede implementar un extremo RESTful que puede mejorar
an ms 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 ms fciles de escalado horizontal cuando stos cumplir esta restriccin y pueden ser
sin estado.
Efectos secundarios Servicios rESTful no deben tener efectos secundarios cuando se solicita un recurso utilizando GET
(Desgraciadamente, esta restriccin es ms fcil 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 ms 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 ningn efecto adicional. Esto es
tranquilizador al generar sistemas confiables distribuidos en los errores, errores de red, o latencia podra producir cdigo para
ejecutar varias veces.
interoperabilidad Muchas personas tout SOAP como el mtodo ms interoperable para implementar programas cliente de
servidor. Pero algunos lenguajes y entornos an no tienen kits de herramientas SOAP. Y algunas que tienen los kits de
herramientas se basan en estndares anteriores que siempre no pueden comunicarse con kits de herramientas que implementan
los estndares ms recientes. REST slo requiere una biblioteca HTTP que estn disponibles para casi todas las operaciones (una
biblioteca XML, of course, suele ser til as well), y es sin duda ms interoperable que cualquier tecnologa RCP (incluyendo
SOAP).
simplificar Esta ventaja es ms subjetiva de los dems 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 direccin URL de piratera, pero no es malvado en modo alguno). Causa de esta
experiencia en mediante los URI para muchos aos, disear los URI para recursos parece muy natural a m. Mediante la interfaz
uniforme simplifica el desarrollo por me liberacin de tener que crear una interfaz, contrato o API para cada servicio que se
necesita para crear. La interfaz (cmo 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 tecnologa slo 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 travs de una red, con independencia del protocolo o
estilo. El concepto de WCF consista en crear un marco que estaba extensibles y conectables para que pueda Obtenga
informacin acerca de un modelo de programacin y la configuracin 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
programacin necesario para hacer uso REST con WCF fcil. Tambin haba algunas partes de la infraestructura que tena 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 programacin y los fragmentos de infraestructura. Y .NET Framework
3.5 SP1 agrega unas pequeas mejoras as.
El modelo de programacin 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 mtodo se va a responder.
La infraestructura se incluye en forma de un enlace (WebHttpBinding) y un comportamiento (WebHttpBehavior) que
proporcionan la pila de red correcta para utilizar REST. Adems, hay algunos ayuda de infraestructura de alojamiento de un
ServiceHost personalizado (WebServiceHost) y un ServiceHostFactory (WebServiceHostFactory).

WebGetAttribute y WebInvokeAttribute
Una de las formas que WCF simplifica la creacin de sistemas conectados es enrutar mensajes de red a los mtodos en
instancias de las clases que defina como las implementaciones de su servicio. Esto permite concentrarse en la lgica del cdigo
en los servicios en lugar de la infraestructura necesaria procesar el trfico de red.
De forma predeterminada, WCF hace esta ruta (tambin conocido como distribucin) segn el concepto de accin. Para esta
distribucin para trabajar, una accin debe estar presentes en cada mensaje que recibe de WCF en su nombre. Cada accin
nica se asigna a un mtodo de accin concreto.
El valor de accin se basa en el nombre de su mtodo (y el espacio de nombres del servicio de) o un valor personalizado
(establecer a travs de la propiedad OperationContractAttribute.Action). Este sistema de distribucin est estrechamente
emparejada para SOAP como encabezado de accin de la especificacin SOAP se utiliza de forma predeterminada.
Afortunadamente, al igual que casi todo lo ms 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 segn no
accin, 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 fcilmente 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 programacin (aunque es a menudo no tenga que hacerlo manualmente,
como se ver ms adelante).
La clave para realizar este trabajo es para que el WebHttpDispatchOperationSelector saber cmo asignar diferentes verbos y los
identificadores URI a los mtodos. Para ello, el WebGetAttribute y WebInvokeAttribute deben agregarse a los mtodos en el tipo
de WCF ServiceContract.
WebGetAttribute indica el distribuidor que el mtodo 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 ms comn). De forma predeterminada, el
identificador URI viene determinado por el nombre del mtodo (agregado en el identificador URI base del extremo).
Esto no es realmente muy RESTful, ya que los nombres de mtodo no lo que desea tratar de REST porque representan verbos.
Qu desea exponer como identificadores URI son los nombres. Por esta razn, el modelo de programacin de WCF REST
permite la personalizacin de URI para cada mtodo mediante plantillas que pueden establecerse a travs de la propiedad
UriTemplate en WebGetAttribute o WebInvokeAttribute.


UriTemplate y UriTemplateTable
Para habilitar la personalizacin del URI para cada mtodo y el verbo de combinacin 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 smbolos (tokens), la estructura
del identificador URI que desea que cada mtodo para representar en combinacin con el verbo HTTP (mediante el
WebGetAttribute o WebInvokeAttribute). Obtendr en la sintaxis con ms detalle en una columna futura.
la figura 2 muestra la definicin de WCF ServiceContract para el servicio MSDN Magazine (con los atributos correspondientes y
personalizaciones UriTemplate) y aplica las caractersticas que he mencionado anteriormente. Extiende el sistema de definicin
de contrato WCF existente con el WebGetAttribute para aquellas operaciones que debe responder a GET. Tambin agrega
WebInvokeAttribute a la operacin para responder a los otros verbos.
La Figura 2 WCF ServiceContract definicin
[ Ser vi ceCont r act ]
publ i c i nt er f ace I MSDNMagazi neSer vi ce
{
[ Oper at i onCont r act ]
[ WebGet ( Ur i Templ at e="/ ") ]
I ssuesCol l ect i on Get Al l I ssues( ) ;
[ Oper at i onCont r act ]
[ WebGet ( Ur i Templ at e = "/ {year }") ]
I ssuesDat a Get I ssuesByYear ( st r i ng year ) ;
[ Oper at i onCont r act ]
[ WebGet ( Ur i Templ at e = "/ {year }/ {i ssue}") ]
Ar t i cl es Get I ssue( st r i ng year , st r i ng i ssue) ;
[ Oper at i onCont r act ]
[ WebGet ( Ur i Templ at e = "/ {year }/ {i ssue}/ {ar t i cl e}") ]
Ar t i cl e Get Ar t i cl e( st r i ng year , st r i ng i ssue, st r i ng ar t i cl e) ;
[ Oper at i onCont r act ]
[ WebI nvoke( Ur i Templ at e = "/ {year }/ {i ssue}", Met hod="POST") ]
Ar t i cl e AddAr t i cl e( st r i ng year , st r i ng i ssue, Ar t i cl e ar t i cl e) ;

}
En este caso, en el mtodo AddArticle agrega (mtodo) = "POST" para facilitar su lectura, como el verbo predeterminado de
WebInvokeAttribute es POST. Tanto los mtodos GET y POST tienen personalizacin 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 mtodos como argumentos.

WebHttpBinding y WebHttpBehavior
En WCF, un enlace determina cmo WCF va a comunicar. Un enlace es realmente la configuracin que indica cmo 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
comunicacin que desee para un extremo especfico de WCF.
Para un extremo RESTful, el enlace que utiliza es WebHttpBinding. A diferencia de muchos otros enlaces, WebHttpBinding es
bastante sencilla, que contiene slo dos componentes: el transporte HTTP y el codificador de mensajes de texto (establecida en
No espera o utilizar SOAP, XML sin formato slo).
Como mencion anteriormente, WebHttpBehavior es el objeto que hace que el distribuidor de identificador URI de ms de
verbo que se va a utilizar, por lo que la WebHttpBinding y la WebHttpBehavior son casi siempre utiliza conjuntamente. Aqu es
el cdigo para crear un extremo tal si se autoalojamiento un extremo RESTful de WCF:




Ser vi ceHost sh =
new Ser vi ceHost ( t ypeof ( MSDNMagazi neSer vi ceType) ) ;
st r i ng baseUr i = "ht t p: / / l ocal host / Magazi neSer vi ce";
Ser vi ceEndpoi nt se =
sh. AddSer vi ceEndpoi nt ( t ypeof ( I MSDNMagazi neSer vi ce) ,
new WebHt t pBi ndi ng( ) , baseUr i ) ;
se. Behavi or s. Add( new WebHt t pBehavi or ( ) ) ;
sh. Open( ) ;
Observe que no slo tengo que especificadas el WebHttpBinding al agregar el extremo final a ServiceHost, tambin debe
agregar explcitamente el WebHttpBehavior al extremo para hacer que funcione el sistema de distribucin de identificador URI
de ms de verbo. Por supuesto, puede hacer esto con configuracin as (consulte la figura 3 ).
Figura 3 identificador URI de ms de verbo y distribucin en la configuracin

<conf i gur at i on>
<syst em. ser vi ceModel >
<ser vi ces>
<ser vi ce name="MSDNMagazi ne. MSDNMagazi neSer vi ceType">
<endpoi nt
addr ess="ht t p: / / l ocal host / Magazi neSer vi ce"
bi ndi ng="webHt t pBi ndi ng"
cont r act ="MSDNMagazi ne. I MSDNMagazi neSer vi ce"
behavi or Conf i gur at i on="webby"/ >
</ ser vi ce>
</ ser vi ces>
<behavi or s>
<endpoi nt Behavi or s>
<behavi or name="webby">
<webHt t p/ >
</ behavi or >
</ endpoi nt Behavi or s>
</ behavi or s>
</ syst em. ser vi ceModel >
</ conf i gur at i on>

WebServiceHost y WebServiceHostFactory
Una de las quejas acerca de WCF es que en ocasiones, es demasiado complejo, especialmente en trminos de configuracin.
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
cdigo para autohospeda con WebServiceHost es similar al siguiente:

st r i ng baseUr i = "ht t p: / / l ocal host / Magazi neSer vi ce";
WebSer vi ceHost sh =
new WebSer vi ceHost ( t ypeof ( MSDNMagazi neSer vi ceType) ,
new Ur i ( baseUr i ) ) ;
sh. Open( ) ;
ste es una optimizacin interesante, ya que evita el cdigo repetitivo de agregar WebHttpBinding y WebHttpBehavior
manualmente. La clase WebServiceHost automticamente 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 seale a la tipo de servicio, ms entradas en el archivo web.config para informar a WCF sobre el extremo (el
enlace y comportamientos entre otra configuracin).
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 configuracin para numerosos servicios RESTful. El archivo .svc tendr este aspecto:

<%@Ser vi ceHost Fact or y=
"Syst em. Ser vi ceModel . Act i vat i on. WebSer vi ceHost Fact or y"
Ser vi ce="MSDNMagazi ne. MSDNMagazi neSer vi ceType" %>
WebServiceHostFactory crea una instancia de la WebServiceHost y puesto que la WebServiceHost automticamente configurar
el extremo con WebHttpBinding y WebHttpBehavior, hay no es necesario que cualquier configuracin de este extremo en el
archivo web.config en todos los. (Por supuesto, si desea personalizar el enlace, debe utilizar el sistema de configuracin o cree
una clase que deriva de WebServiceHost/WebServiceFactory). Si necesito personalizar el enlace, todava puede agregar las
entradas adecuadas en el archivo configuracin. la figura 4 muestra un archivo de configuracin que debe activar la
autenticacin bsica HTTP en el extremo de servicio.
La figura 4 activar autenticacin bsica HTTP

<conf i gur at i on>
<syst em. ser vi ceModel >
<ser vi ces>
<ser vi ce name="MSDNMagazi ne. MSDNMagazi neSer vi ceType">
<endpoi nt
addr ess="ht t p: / / l ocal host / Magazi neSer vi ce"
bi ndi ng="webHt t pBi ndi ng"
cont r act ="MSDNMagazi ne. I MSDNMagazi neSer vi ce"
behavi or Conf i gur at i on="webby"/ >
</ ser vi ce>
</ ser vi ces>
<bi ndi ngs>
<webHt t pBi ndi ng>
<bi ndi ng name="secur e">
<secur i t y mode="Tr anspor t ">
<t r anspor t cl i ent Cr edent i al Type="Basi c"/ >
</ secur i t y>
</ bi ndi ng>
</ webHt t pBi ndi ng>
</ bi ndi ngs>
<behavi or s>
<endpoi nt Behavi or s>
<behavi or name="webby">
<webHt t p/ >
</ behavi or >
</ endpoi nt Behavi or s>
</ behavi or s>
</ syst em. ser vi ceModel >
</ conf i gur at i on>



Utilizar el cdigo de ejemplo
Mediante la explicacin de las caractersticas de WCF en relacin con REST, ha disponen la mayor parte de la implementacin
del servicio que propuesto al principio de la columna de. Permtanme recorra interactuar con este servicio.
Una vez que tenga el servicio de seguridad y en ejecucin, puede aciertos su raz URI con cualquier cliente, incluido un
explorador Web tal Internet Explorer. Ser capaz de ejecutar pruebas rpidas 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 raz
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 ao
determinado, slo PUEDO agregar ese ao a la direccin (URI) en el explorador (consulte la figura 6 ).

Figura 6 el recurso de representacin del ao 2007
Si le pregunte para octubre de 2008, el identificador URI sera localhost:1355/Issues.svc/2008/october, que, en este momento,
podra ser un conjunto vaco. Y si desea agregar un artculo, podra hacer un HTTP POST a ese identificador URI con la
representacin XML de un artculo como el cuerpo de la solicitud HTTP.
Otra caracterstica interesante de HTTP es todas las herramientas que estn disponibles para interactuar con l. Uno de mis
favoritos es Fiddler , que permite espa de solicitudes HTTP y las respuestas. Pero tambin tiene una caracterstica 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 despus la POST en la
figura 8 .

La figura 7 cmo hacer que un HTTP POST solicitud para crear un nuevo recurso de artculo con
Fiddler

Figura 8 agregada recursos de artculo
Aunque se puede argumentar que Internet Explorer y Fiddler son clientes reales, creacin de una implementacin real de cliente
/ servidor es una extensin de estos pasos simples que slo fue (un ejemplo ms complejo de creacin de que un cliente
RESTful vendr en una columna de una versin 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 continuacin, el cliente puede interactuar con el servicio
mediante el uso estas piezas de informacin para crear su funcionalidad.
Lo que he mostrado en esta primera columna es el conjunto base de caractersticas WCF que habilitar el estilo de la arquitectura
REST para utilizarse en las aplicaciones .NET con facilidad. Esta base permite otras tecnologas interesantes, incluidas cosas tales
como las fuentes Web (RSS y Atom) y compatibilidad con recursos de JSON codificada para la interaccin con AJAX.
En las columnas algunas siguiente, voy a esta base conocimientos de REST y WCF y profundizar en los detalles de varias otras
caractersticas de la plataforma de Microsoft que se basan en este estilo y la tecnologa. Tambin se le tratar con algunas de las
preguntas ms frecuentes de REST, por ejemplo, sobre seguridad y sobre la idea de implementar los extremos de
procesamiento.