FiveTech Software tech support forums

Hola a todos,
Acabo de publicar el Harbour Magazine la primera colaboración de Rafa Carmona en la publicación.
* Servidor RestFul con Harbour - https://medium.com/harbour-magazine/servidor-restful-con-harbour-935ed2fe8615
Saludos,

Hello,
I've just published the first Rafa Camona's post at Harbour Magazine:
* RestFul server with Harbour - https://medium.com/harbour-magazine/res ... 5e59335cf7
Regards,

José Luis Sánchez

Genial, que gran trabajo!!.

Rafa,

Un gran artículo explicando todo esas “cositas” que tenemos y no sabemos… Gracies, una gran currada.

Abrazos.

C.

Agradezco a Rafa y a José Luis su esfuerzo en traernos luz sobre lo desconocido de Harbour.

Ahora bien, no sé si entiendo "de qué va" lo del Restful.

A ver. Lo que yo entiendo es que se trata de un programa servidor, servicio win, demonio o exe, dando servicio a las peticiones que se le hacen desde un programa cliente, al que se le suministran respuestas probablemente en JSon, todo moviendose por http.

¿ Para qué podría servir ? Pues, por ejemplo, para "servir" información de los datos de una aplicación de escritorio.

¿ Es eso ?

A ver si por favor alguien me puede sacar de dudas y así puedo centrarme mentalmente el artículo de Rafa, que tan amablemente, ha escrito.

Saludos

Correcto!

Todo app de ios o Android funciona exactamente así. Imagina que quieres hacer un app en Android con FiveTouch, por poner un ejemplo, puedes
alimentar tus DBFs en Android, a traves de un servidor RestFul , realizado en Harbour, que te pasa la info en JSON.

Saludos Cordiales

Rafa,
muy buena explicación y un ejemplo muy práctico. Muy útil para exportar los datos de las aplicaciones que usan dbfs, aunque no se que tal lo llevan los hilos que se ejecutan en paralelo y las workareas.
Una pregunta: ¿Como manejas la autenticación? ¿Hay algo ya hecho en httpd?

Un saludo

Buenas Carlos

Los hilos en Harbour funciona muy bien en mi expericiencia, y cuando se crea un hilo, la apertura de una tabla , y su alias, solo es visible en ese hilo.

Por lo tanto, puedes abrir un hilo que contenga ;
USE CLIENTES NEW
clientes->nombre sin problemas, el mismo alias en hilos independientes.

Respecto a la autentificación, si lo usas como servidor web, simplemente usas una función , creo recordar, uSessionStart, en el ejemplo que tienes en contrib lo tienes.

Si lo que pretendes usarlo como RestFul,al no tener estado, lo suyo es usar una cabecera de autorizacion 'Authorization', 'Basic' .
Otros mecanismos lo que hacen es que tienes que soliciar un token, que es temporal limitado en el tiempo, y usas para hacer la petición en una cabecera del http
introduciendo ese token, o en el mismo JSON de petición.

Hola Rafa,

perdona la brasa pero hay algo que no me queda claro: En el Main hay unas variables Memvar: server, get, post, etc... ¿Esas como juegan? ¿Son por cada hilo?


Slds

Rafa,

Que opinas de este ejemplo en PHP ? Se ve muy simple y si se necesita más, el autor proporciona todo lo que falta

https://www.leaseweb.com/labs/2015/10/creating-a-simple-rest-api-in-php/

Un detalle fino respecto a las generalidades del REST: El uso de PUT queda en aquellos casos donde enviamos el registro o entidad completo, y PATCH si no incluímos todos los campos.
Hace poco hice un curso de Node/Express y Mongo e hicieron hincapié en ese concepto, que las primeras implementaciones no tuvieron presente pero que con el tiempo han tomado fuerza.

Una discusión interesante al respecto: https://stackoverflow.com/questions/284 ... e-examples

Respecto del ejemplo que propone Antonio, el artículo es bastante detallado: escribir poco código. Al final hace un listado de todas las 'pegas' o cosas que le faltan, e incluye algo que me suele preocupar bastante: seguridad. Está también el enlace al proyecto completo, y esta muy interesante.

Google API utiliza siempre PATCH para indicar Modificación

Hola,

Intentaré ser lo mas breve que pueda pero son temas que se han de abrir poco a poco por aqui... Siempre he comentado que es un tema apasionante y un debate muy interesante, a la vez muy amplio y a la vez tan complejo como queráis llegar cada uno de vosotros. Podrás leer especificaciones, normas, entrar en fórums, … y a la vez podrás observar que incluso muchos de los especialistas en este campo ni se ponen de acuerdo (jejeje que raro, no?).

Recuerdo hace años años un post sobre pocket pc en que respondia que microsoft te pegaba un “rollo patarero”… y Antonio contestaba … es el arte de complicarse la vida. Pues eso, a veces queremos ser tan “puristas” que el árbol nos tapa el bosque.

Mi punto de vista es el siguiente: Uno puede intentar comprender el sistema, puede implementarlo siguiendo unas normas o quizás una filosofía, pero al final el objetivo es que funcione correctamente. Puedo saber que según HTTP RFC especifica que un PUT afecta a una representación completa como entidad de la solicitud y PATCH solo parte. Asi suelen funcionar WS (webservices) de google, amazon,… pero hay miles de sitios que tu haces un PUT para modificar parte p.e. de un registro. Y QUE ? Funciona igual y no pasa nada. Que es incorrecto ? Quizás o no, no lo se pero funciona.

Al final lo que debo saber es que si mi sistema se conecta a un WS p.e. de google para q pueda modificar algo del calendario, pues me obligaran a usar PATCH, porque es su diseño (vale y quizás bien hecho según protocolo, un standard, tal y cual).

Pero yo puedo hacer mi WS, que como entendemos da un servicio a alguien y mi API que he diseñado siga un patrón diferente y aquí es donde todos creo que debemos poner el foco. Es el concepto de la API que montemos y diseñemos, voy a poner los VERBOS que me gusten y listos.

Al final el WS recibe una petición y escupe un resultado. Esto es el principio básico. Y nuestro servicio a mi entender ha de realizar lo siguiente:

- Control de Seguridad (Como dice Carlos, tema importantísimo)
- Validacion de parámetros
- Controlar la petición (Aquí es donde entran tantos verbos y tanta historia. O no ¡)
- Ejecutar acción
- Devolver respuesta (json, xml,…)

Vale esta es la base. Cada uno de sus puntos tiene su rollete, pero la base para crearnos nuestro WS es esta y a partir de aquí construimos la API necesaria para trabajar. Pensad que si nosotros generamos un WS para que algún dia alguien de una empresa externa se conecte, nosotros le daremos nuestras especificaciones que se pueden adaptar mas o menos al concepto universal, purista, etc… De la misma manera que si nosotros queremos que nuestro sistema se conecte a otro externo nos debemos adaptar a su protocolo y especificaciones.

Y seguiremos...

Pues asi es, un tema muy "calentito"
Yo no entiendo como funcionalidad el hecho de que las tareas que se realizan y que son transparentes al usuario, y que como el usuario obtiene lo que requiere, todo vale.
Yo también he visto accesos a WS que utilizan REST que usan otros verbos ( estándard o diseñados por nosotros ) para indicar las acciones a realizar: incorrecto?, no, evidentemente, eso es lo que nos dice su filosofía de desarrollo siempre y cuando junto al uso de estos verbos sigan cumpliendo las demás normas.
He visto que otros WS utilizan también verbos standard para realizar acciones que no se contemplan en la norma: bien, si así ha sido diseñada y documentada, por qué no, siempre y cuando, insisto, sigan cumpliendo las demás normas en el diseño del API.
Pero me he encontrado con otros casos en los que por ejemplo utilizan el PUT para indicar una modificación enviando a través de los parámetros de la dirección de acceso el dato(s) a modificar ( ?nombre="Pepe"&edad="23" ), y funciona?, claro, si así lo has diseñado, pero es correcto según las normas?, no, entre otras cosas porque estás poniendo posiblemente en peligro la integridad de la seguridad de tu WS.
O sea, como siempre, estamos en la dualidad de seguir las normas o hacer que la "funcionalidad" esté por encima de ellas porque nos facilita el desarrollo al programador.
Creo que esas normas se crearon para asegurarnos que siguiéndolas nos va a facilitar mucho el desarrollo de las APIS ( evidente, ya que cada verbo tiene su funcionalidad y no tenemos que andar incluyendo en nuestro código IF innecesarios que, seguramente penalizaran la velocidad de ejecución ). El caso más habitual es desarrollar el PUT y como ya nos funciona la grabación en la base de datos, pues la "aprovechamos" para que sólo nos grabe parte del registro.
Funcionalidad VS optimización:
El ejemplo que puedo poner ( utilizando una DBF por ejemplo sin hablar de REST ) es realizar una modificación en un campo de un registro de una base de datos, y diseñar nuestro sistema para que grabe todo el registro de nuevo: funcionar, si funciona, y como siempre, bajo el punto de vista de la funcionalidad, como es transparente al usuario, todo va bien, pero, es correcto?, no, entre otros temas porque en un ambiente de red, hacemos que el servidor y el uso de la red se esté cargando innecesariamente, o borrar todo el registro y volverlo a grabar entero, funciona?, sí, evidentemente, pero, creo que podremos entender que no es lo que deberíamos hacer al diseñar nuestro sistema, ya que las RDDs nos ofrecen funciones para cada una de las acciones que podemos realizar en una base de datos con el fin de optimizar su uso y diseño.
Saludines