Se ha hecho muy popular el uso de los APIs (Application Programming Interface) en el mundo de desarrollo de aplicaciones en estos días. Actualmente encontramos los API en todas las redes sociales populares. Facebook, Twitter, Instagram, Tumblr y muchas más, cuentan con sus propio API para interactuar con otras aplicaciones y servicios. Y es que esa es la esencia de los APIs, es una manera de interactuar con algún servicio o aplicación. Hay varias maneras en la que esta comunicación sucede pero la que me interesa discutir hoy es a través de HTTP haciendo uso de un servicio web.
Imaginemos que queremos desarrollar una aplicación móvil en la que cada vez que presionemos un botón nos muestre un chiste nuevo. En los teléfonos inteligentes no podemos instalar ninguna bases de datos robusta. Es cierto que podemos utilizar SQLite pero no es lo ideal ya que esta base de datos se utiliza, mayormente, para almacenar la configuración de la aplicación. Ya que no tenemos base de datos disponible en el teléfono inteligente, nos queda utilizar un API o servicio web que nos comunique con una base de datos a un nivel central y que sea esta quien nos provea los chistes cada vez que el usuario presione el botón.
Construyendo el servicio web (API)
Primero abrimos Visual Studio, en mi caso voy a estar usando Visual Studio 2012, y creamos un nuevo proyecto de tipo WCF Service Application y lo nombramos ServicioChistes.
Luego de haber creado el proyecto, lo próximo que queremos hacer es borrar el servicio que el proyecto crea llamado Service1.svc y IService1.cs y crear un servicio con el nombre que deseemos. Así que en el proyecto añadimos un nuevo servicio y lo llamamos Chistes.svc.
Este último paso que hicimos nos va a crear dos archivos nuevos: Chistes.svc y IChistes.cs. IChistes.cs es la interface donde vamos a definir cómo la comunicación se va a llevar a cabo. Chistes.svc, por el otro lado, es donde vamos a implementar y escribir la funcionalidad de lo que nuestro servicio web estará haciendo.
En la interface IChistes.cs vamos a escribir el siguiente código:
[OperationContract]
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "nuevochiste")]
string NuevoChiste();
[OperationContract]
[WebInvoke(Method = "GET", ResponseFormat = WebMessageFormat.Json, BodyStyle = WebMessageBodyStyle.Wrapped, UriTemplate = "nuevochistecat/{categoria}")]
string NuevoChisteCategoria(string categoria);
Lo que estamos diciendo en el código anterior es que estaremos implementando 2 métodos. El primero nos va a devolver un chistes aleatoriamente, mientras que el segundo nos va a devolver un chistes de la categoría que le enviemos en el parámetro. Hay varias cosas importantes que vale la pena mencionar del código anterior. Primeramente, estamos diciendo que vamos a estar utilizando GET como método de comunicación (Method = “GET”). Como ya sabemos, HTTP tiene 4 métodos de comunicación:
- GET – Solicita una representación específica de un recurso
- PUT – Crea o actualiza un recurso
- DELETE – Elimina el recurso especificado
- POST – Suministra data para ser procesada
Segundo, estamos diciendo que la comunicación se llevará a cabo en el formato JSON (ResponseFormat = WebMessageFormat.Json). Usamos este formato porque es uno sumamente fácil de entender y de utilizar. Si este formato no es de su preferencia, puede usar, también, XML. Y tercero, que el URL al cual vamos a llamar tendrá como sufijo /nuevochiste para llamar el primer método y nuevochistecat/{categoria} para llamar el segundo método. Donde {categoria} no es otra cosa que el parámetro que vamos a estar enviando.
Muy bien, ya tenemos la definición de nuestro servicio. Solo falta implementar estos 2 métodos. Para esto abrimos el archivo Chistes.svc.cs y creamos los métodos previamente definidos.
public string NuevoChiste()
{
string chiste = "";
/*Logica para obtener el nuevo chiste de la
base de datos*/
return chiste;
}
public string NuevoChisteCategoria(string categoria)
{
string chiste = "";
/*Logica para obtener el nuevo chiste de la
base de datos*/
return chiste;
}
De esta manera terminamos de construir nuestro servicio web o API. Sin embargo, nuestro trabajo no ha terminado aún. Tenemos que adaptar el web.config de nuestro proyecto para que el servicio pueda ser accedido desde cualquier fuente (javascript, .Net, java, etc.).
Web.config
De manera que podamos usar nuestro API desde cualquier ambiente, ya sea .Net, javascript, java, o cualquier otro lenguaje, necesitamos configurar varios elementos en el archivo web.config de nuestro proyecto. Y es que necesitamos dejar claro los famosos “endpoints” que nos dicen que protocolo y el URI por el cual la comunicación se va a llevar a cabo.
Lo primero que tenemos que hacer es añadir la sección de services bajo la sección system.serviceModel.
<services> <service name="ServicioChistes.Chistes" behaviorConfiguration="ServiceBehavior"> <endpoint address="" binding="webHttpBinding" bindingConfiguration="webHttpBindingWithJsonP" contract="ServicioChistes.IChistes" behaviorConfiguration="web"></endpoint> </service> </services>
En las lineas anteriores lo que dijimos fue que vamos a estar utilizando un servicio cuyo nombre es “name=”ServicioChistes.Chistes”” y que va a usar la configuración definida en la sección con nombre ServiceBehavior (behaviorConfiguration=”ServiceBehavior”). Además, tenemos definido nuestro primer “endpoint” con su configuración correspondiente. Esta configuración que hace referencia el elemento “service” y “endpoint” hay que definirlas para que el servicio web funcione adecuadamente.
Bien, primero definimos la configuración del servicio llamada ServiceBehavior. La misma va dentro de la sección dentro de . En esta sección configuramos que tipo de metadata queremos que el servicio comparta.
<behavior name="ServiceBehavior"> <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/> <serviceDebug includeExceptionDetailInFaults="false"/> </behavior>
Próximo, definimos la configuración de nuestro “endpoint” en la que le decimos al servicio a través de que protocolo nos vamos a estar comunicando.
<endpointBehaviors> <behavior name="web"> <webHttp/> </behavior> </endpointBehaviors>
Por último, necesitamos configurar las reglas de la comunicación a través de HTTP. Esta sección es importante si queremos que el servicio web pueda ser utilizado desde código javascript a través de llamadas de otro dominio (Cross Site Scripting).
<bindings> <webHttpBinding> <binding name="webHttpBindingWithJsonP" crossDomainScriptAccessEnabled="true" /> </webHttpBinding> </bindings>
Finalmente tenemos nuestro web.config en su totalidad.
<?xml version="1.0"?>
<configuration>
<appSettings>
<add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" />
</appSettings>
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5"/>
</system.web>
<system.serviceModel>
<services>
<service name="ServicioChistes.Chistes" behaviorConfiguration="ServiceBehavior">
<endpoint address="" binding="webHttpBinding" bindingConfiguration="webHttpBindingWithJsonP" contract="ServicioChistes.IChistes" behaviorConfiguration="web"></endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/>exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="web">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
<protocolMapping>
<add binding="basicHttpsBinding" scheme="https" />
</protocolMapping>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
<bindings>
<webHttpBinding>
<binding name="webHttpBindingWithJsonP" crossDomainScriptAccessEnabled="true" />
</webHttpBinding>
</bindings>
</system.serviceModel>
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"/>
<directoryBrowse enabled="true"/>
</system.webServer>
</configuration>
Ahora nuestro servicio esta listo para ser publicado y utilizado por todos aquellos que quieran un reírse un poco por un chiste.
Conclusión
Los APIs son una manera efectiva, y fácil de implementar, de compartir información y proveer servicios. Actualmente es utilizada por las grandes redes sociales y es la pieza clave para que todos estemos conectados a ellas. Si aún no has escrito ningún API te exhorto a que intentes esta herramienta que ha tenido tanto éxito en estos últimos años.
No olvides comentar sobre como los APIs te han ayudado en tus proyectos o si tienes alguna duda en la que te podamos ayudar. Espero saber pronto de ustedes.
