Posts Tagged: api


3
abr 12

RESTful API Frameworks en PHP

No Gravatar
REST vs SOAP

RESTful services

La semana anterior liberé la versión 0.4.0 de Celestic y una cosa que había prometido y que al final no logré hacer era escribir una API en REST para  utilizarla desde equipos móviles.. Bueno, al menos hay una versión preliminar pero decidí no subirla a los respositorios de código porque eran pruebas .. y es que durante varios días estuve investigando y probando herramientas para el desarrollo de esta API, al final no utilicé ninguno de estos frameworks y estoy escribiendo mi propia extensión para Yii la cual funcionará tomando datos de los modelos y exportando los resultados a json y xml..

Entonces al grano, esta es una lista de frameworks o librerías que podrían ayudarte a construir tu propia API en REST sobre PHP ..

FRAPI – Fue una de mis primeras opciones.. pero después de pocos minutos revisando como instalarlo y configurarlo lo abandoné porque al ver que tenía una parte de administración y otra de consumo me desanimé.. en realidad lo que buscaba era algo más simple.. Desde la interfaz de administración y también consola se pueden crear acciones (esto viene hererado del MVC donde solicitas a un controlador una accion específica que termina siendo un método a ejecutarse).

APIFY – Muy parecido a Frapi, incluso al descomprimirlo vemos una estructura de carpetas tipo MVC.. lo probé pero por alguna razón que aun desconozco nunca funcionó.. su documentación es muy escasa.. en realidad toma muchas cosas de Zend Framework y la librería base para crear REST se reduce a clases Request y Response.

Recess – No tuve oportunidad de probarlo a fondo, al igual que los demás utiliza el patrón de diseño MVC, su interfaz para el desarrollo del servicio esta basado en web a través del navegador. Creo que es de los mejores, pero tiene bastantes archivos y eso no me gustó mucho. Utiliza PDO y mapeo de basee de datos, punto negativo creo que son las consultas entre tablas anidadas.

Slim – No tuve ganas de probarlo, aunque a diferencia de los demás Slim no es un framework, sino más bien una librería o un set de librerías.. Me gustó cuando ví el código pero me desanimó el hecho de que utilizan sus propias rutas y la ausencia de activeRecords.

Tonic – También es una librería, es bastante simple para lo que buscaba y de las cosas que alcancé a probar pues de eso decidí mejor construir mis propias clases para generar REST, me dió la impresión de que me ahorra muy pocas cosas..

En general todos los frameworks y librerías son muy buenos para trabajar utilizando su propio esquema o estructura de carpetas.. Un punto negativo que tienen todos es que los que utilizan PDO y model mapping no es muy bueno con los join y las consultas complejas puede que sea un dolor de cabeza.. Ninguna utiliza un esquema de autenticación compleja como OAuth o al menos Basic Auth .. y si utilizan seguridad lo hacen mediante un parámetro extra que se envia por la url..

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

27
mar 12

Consumiendo REST desde C#.NET

No Gravatar
Consumir RESTful en .NET

Consumir RESTful en .NET

Hace algunos días atras buscaba una forma decente y elegante de crear mi propia api utilizando RESTful para Celestic .. de esa forma fue que llegue a StackOverflow y muchas preguntas de usuarios necesitando código para consumir servicios basados en REST.. En este sitio todavía no colaboro por lo que no quize responder, ya pensándolo bien fue que decidí escribir este artículo.

Sé que hay otra manera de hacerlo.. pero para este ejemplo utilizaremos el objeto HttpWebRequest y HttpWebResponse, entonces comenzamos:

var postString = new {clave1:valor1, clave2:valor2};
byte[] data = UTF8Encoding.UTF8.GetBytes(postString);
 
HttpWebRequest request;
request = WebRequest.Create("http://localhost/ejemplo/api") as HttpWebRequest;
request.Timeout = 10 * 1000;
request.Method = "POST";
request.ContentLength = data.Length;
request.ContentType = "application/json; charset=utf-8";

Básicamente lo que se hace es instanciar de HttpWebRequest y setear algunos parámetros, entre ellos y mas importante el método (Method), la longitud de la petición (ContentLength) y el tipo de dato a enviar (ContentType). No pierdan de vista que estoy enviando postString que a su vez es un objeto tipo Json.

La mayoría de servicios basados en REST requieren autenticación básica.. y pues es una de las más fáciles de utilizar.. inclusive desde el navegador se puede hacer, lo único que se requiere es un usuario y una clave de acceso..

string credentials = Convert.ToBase64String(ASCIIEncoding.ASCII.GetBytes("usuario:clave"));
request.Headers.Add("Authorization", "Basic " + credentials);

Esto es como algunas páginas en internet que piden autenticación para entrar, donde puedes escribir la url y esperar a que aparezca el formulario de inicio de sesion o escribirlo directamente en la url.. de la forma: “usuario:clave@http://localhost/ejemplo/api”

Ahora lo siguiente y último paso es enviar los datos y obtener la respuesta..

Stream postStream = request.GetRequestStream();
postStream.Write(data, 0, data.Length);
 
HttpWebResponse response = request.GetResponse() as HttpWebResponse;
StreamReader reader = new StreamReader(response.GetResponseStream());
string body = reader.ReadToEnd();

Y para finalizar body es el contenido de lo que ha respondido el servicio, recuerden que la respuesta es tipo Json.. por lo que pueden interpretarla facilmente con javascript o hacer algo más complejo si desean parsearlo desde .NET.

Espero les sirva el código.. y si encuentran algun error, recuerden que el formulario de comentarios no muerde.. :D

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

14
feb 12

REST vs SOAP

No Gravatar
REST vs SOAP

REST vs SOAP

Aunque REST y SOAP son arquitecturas muy similares de intercambio de información entre aplicaciones web y de escritorio con servidores, antes de decidirse por uno de ambas es importante tener en cuenta las siguientes consideraciones. Trataré de ser objetivo en este artículo ya que hasta hace poco empecé a utilizar REST (4 meses), todo lo que aprendí sobre websvices esta basado en SOAP.

Primeramente hay que entender que REST esta basado en una arquitectura donde se identifican los recursos claves a consumirse.. veámoslo como una forma semántica de escritura ante la web donde hay métodos que al ser interpretados nos retornan información… Algo como por ejemplo utilizando el método GET del protocolo HTTP (digo GET porque también se puede utilizar POST, PUT, HEAD, DELETE, etc.. ) haría una petición de la siguiente manera: “http://servidor.com/api/proyecto/1/tarea/5″  .. donde api es el contenedor de mi webservice y lo que sigue sería equivalente a decir.. Del proyecto con identificador no. 1 seleccionar la tarea con identificador no. 5 y mostrar el resultado en formato json o xml.

Así de fácil es REST, mientras que SOAP es un poco más complicado por que lo que se consumen son métodos o funciones almacenadas igualmente en un servidor.. entonces si quisiera hacer lo mismo.. en SOAP tendría que escribir algo como lo siguiente: “http://miservidor.com/api/calcula” donde calcula contiene una definición de funciones (sumar y restar) que se pueden implementar mediante la creación de un objeto, un concepto de la programación orientada a objetos .. del uso de alguno de los métodos listados en el servicio calcula como respuesta obtendría una salida en xml con una definición del tipo de datos que respondió el servidor..

Si se fijan ambos tipos de conexión ya sea REST o SOAP se parecen mucho, ya que sirven para solicitar información a un servidor, pero distan de implementarse de una manera similar.. verán que REST es mucho más fácil y SOAP conlleva escribir un poco más de código..

En la actualidad muchos de los servicios que utilizamos a diario como twitter, facebook, fourquare, delicious, flickr, etc.. estan basados en REST por la facilidad de imlementación y la simplesa que se obtiene en los resultados.

SOAP ya que tiene una arquitectura de respuesta más compleja, es utilizado comunmente en corporaciones, hasta me atrevería a decir que la mayoría de empresas que utilizan sistemas basados en .NET o Java tienen sus servicios de comunicación basados en SOAP .. porque ha decir verdad es muy fácil implementar esos objetos y consumir esos métodos.. porque claro!! hay personas que ya hicieron todo el trabajo pesado de crear librerías que se usan casi con un par de líneas. Además que en estos lenguajes se tienen componentes visuales que se conectan casi de manera transparente a webservices basados en SOAP por lo que como dije.. ya todo lo interesante ya se hizo.

Entonces ya que tenemos una mejor idea de que hace REST vs SOAP podemos hacer comparaciones y obtener una conclusión..

REST

En lo que es genial

  • Es muy ligero, sus respuestas contienen exactamente la información que necesitamos.
  • Para los nosotros los humanos es muy fácil y simple de interpretar.
  • Es sencillo de desarrollar y no se necesita mucho código extra.
  • Es flexible en cuanto al tipo de respuesta que se necesita, ya que puede ser xml o json.
En lo que falla
  • Creo que la seguridad es un problema y puede llegar a ser una tarea muy difícil implementarla correctamente.
  • No hay un estándar en sus respuestas por lo que no se definen tipos de datos.
SOAP

En lo que es genial

  • Si trabajas con componentes y utilizas .NET o Java es muy sencillo de consumir.
  • El resultado que siempre es XML contiene una definición específica del tipo de dato, lo que hace del protocolo algo muy estricto.
  • Se dice que es más seguro porque su implementación siempre o la mayoría de las veces se hace del lado del servidor.

En lo que falla

  • Una vez implementado, si se desea cambiar algo en el servidor impacta de forma negativa en los clientes ya que estos tienen que hacer muchas modificaciones al código.
  • Las respuestas son demasiado complejas y difíciles de interpretar si no se tienen las herramientas correctas para hacerlo.

Conclusión

Creo que ambas arquitecturas de intercambio de información tienen sus nichos bien definidos, cuando se trata de aplicaciones públicas refiriéndome a servicios de uso masivo es mucho mejor utilizar REST por la sencillez en su implementación y respuestas, inclusive en clientes móviles es mucho más fácil utilizar REST. Por otro lado si se esta pensando en webservices para corporaciones donde se manejan datos complejos y se necesita una presición detallada en las respuestas se debe de utilizar SOAP, entornos de desarrollo como Visual Studio hacen que el desarrollo e implementación de SOAP sea sumamente sencillo sin tener que escribir código de más para interpretar respuestas.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

7
feb 08

Envío de mensajes masivos usando Dcod SMS

No Gravatar

Avances de DcodSMS

Ya hace algunas semanas atrás habiamos estado trabajando en una aplicacion multiplataforma para envío de mensajes SMS a celulares en toda la república mexicana y algunos países de latinoamérica, actualmente el servicio ya deja de ser un alpha y pasa a ser un beta ya funcional, el cual puede ser accedido desde http://sms.dcod.com.mx/ la aplicación ha mejorado mucho, soportando envíos simultaneos masivos, no como anteriormente que se enviaba 1 mensaje a la vez.. Creo que antes había comentado también que cambiamos de plataforma de desarrollo y de servidor, para mantener mayor estabilidad nuestro servidor ahora se basa en apache sobre linux, lo veo mucho mejor que IIS. Esta nueva versión en estado beta viene cuenta con una interfaz web desde la cual pueden enviarse mensajes, consultar saldos, consultar estado de envío y ver historial de mensajes enviados. Los Webservices estan terminados y han sido probados con lenguajes como Delphi, C#, PHP, Flash, Flex, y Java, todavía faltan algunos otros pero seguimos desarrollándolos como ejemplos. Actualmente estamos elaborando la documentación para uso del API y algunos casos de uso en diferentes lenguajes de programación; la ayuda e información adicional puede ser obtenida desde http://sms.dcod.com.mx/wiki/index.php/Portada. El servicio continua desarrollándose y esperando nuevas ideas para mejorarlo.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

Qbit Mexhico Blog is using WP-Gravatar