Hola, Ale. Para mi tratar de hacerlo a través del navegador tiene patas cortas. REST o incluso un API Json que no sea del todo REST, no es fácil manejar desde dentro del HTML. Hay operaciones que el navegador no hace de manera pura (POST, DELETE, etc) porque salen desde un formulario y están pensadas para un uso interactivo. Los servicios tienen otros requerimientos.
Esa diferencia es la que implementó Pablo en IFox, casualmente, para que puedas hacerlo sin navegador. Abrazo, --- Martín Salías <http://CodeAndBeyond.org> <http://CodeAndBeyond.org> 2014-06-18 16:56 GMT-04:00 Alejandro Paciotti <[email protected]> : > Bueno, seguramente la opción"ma mejor" es la de Pablo Pioli, o sino, > podrían intentar aprender Angular, Node.js y hacer un ejecutable que reciba > parámetros para que postee en el servicio rest. > > O bien hacerlo desde Fox... > > Esto es solo una idea que tuve, no tuve tiempo de probarla... > > LOCAL lcUserName, lcPassword > > *lcUserName* = 'alguien' > *lcPassword* = 'supersecreta' > > TEXT TO PostearEnUnServicioREST TEXTMERGE NOSHOW PRETEXT 2 > <html ng-app='unaAplicacion'> > <head> > <title></title> > <script src=' > http://cdnjs.cloudflare.com/ajax/libs/angular.js/1.2.16/angular.min.js > '></script> > </head> > <body ng-controller='unControlador'> > > <script> > var App = angular.module('unaAplicacion', []); > > App.controller('unControlador', function ($scope, $http, $window) { > $scope.user = {username: '<<*lcUsername*>>', password: '<<*lcPassword* > >>'}; > > $scope.submit = function () { > $http > .post('http://localhost:3000/api/clientes/login', $scope.user) > .success(function (data, status, headers, config) { > > * // Acá recibiríamos estos objetos si el usuario y > psw están ok.* > > > } > .error(function (data, status, headers, config) { > * // Por acá vendría si está todo mal.* > > } > </script> > </body> > </html> > ENDTEXT > > * > > STRTOFILE(PostearEnUnServicioREST, 'postear.html') > > Y después, automatizar un navegador para que abra el postear.html. > > De todas formas, creo que la idea de consumir un servicio REST desde FOX > quedó contestada. > > *Abrazo de gol sobre la hora!* > > > [email protected] > > > El 18 de junio de 2014, 16:52, Martín Salías <[email protected]> > escribió: > >> ¿Al final lo hiciste? ¡Sos un grosso! >> >> Hay tienen el canal más directo, entonces. :) >> >> Abrazote, >> >> --- >> Martín Salías >> <http://CodeAndBeyond.org> >> <http://CodeAndBeyond.org> >> >> >> 2014-06-18 15:02 GMT-04:00 Pablo Pioli <[email protected]>: >> >>> A lo que Martin explica tan bien agregaria 2 cosas. >>> >>> >>> 1. Lo de .../api/clientes/nuevo >>> no es justamente REST estricto porque generalemente viene de otro lado, >>> del MVC (el nuevo es el metodo del controller). Justamente Microsoft tiene >>> ASP.NET MVC y WebAPI (para arquitecturas REST) para que eligas como lo >>> quieras implementar. >>> >>> 2. Si a alguien se le ocurre hacerlo con iFox se puede, si bien fue >>> pensado para hacer POST de formularios le agregue la posibilidad de cambiar >>> el content-type y el metodo (post, put, etc). >>> No queda de lo mas lindo porque es como un parche arriba pero funciona. >>> >>> Pablo Pioli >>> >>> El 18/06/2014 01:57 p.m., Martín Salías escribió: >>> >>> Hola, Ale. >>> >>> La explicación está bien, con una salvedad (si queremos que el >>> servicio sea REST): >>> >>> La URI para el saldo de clientes de tu ejemplo, siempre debería ser: >>> >>> http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/saldoclientes/ >>> <http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/saldoclientes/json> >>> >>> Porque ese es el recurso. Si quisieras los datos de un cliente en >>> particular, sería algo como: >>> http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/3324/ >>> <http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/saldoclientes/json> >>> >>> Cuando vos (desde tu aplicación cliente) hacés un GET a esas URI, en >>> el header le vas a decir el Content Type que querés (JSon o XML, por >>> ejemplo) y el servicio te va a devolver uno u otro, o decirte que no lo >>> soporta >>> >>> De la misma manera, cuando querés dar de alta un cliente, por ejemplo, >>> hacés un POST a: >>> http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/ >>> <http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/saldoclientes/json> >>> >>> ...no a "clientes/nuevo". El response de este POST, si creo un nuevo >>> elemento, debería ser 201 (no 200), y darte la URI de la nueva entidad en >>> Location, por ejemplo: >>> >>> http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/ >>> <http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/saldoclientes/json> >>> 7889 >>> >>> ¿Se entiende la diferencia? >>> >>> Igual es bueno aclarar que esto es un servicio REST correcto, y si lo >>> que tenés es que consumir un servicio que "dice" ser REST, muchas veces >>> nada de esto aplica, y tenés que ver qué es lo que hay que hacer (que es lo >>> que no deberías si fuera RESTful). >>> >>> Saludos, >>> >>> >>> >>> >>> >>> --- >>> Martín Salías >>> <http://CodeAndBeyond.org> >>> >>> >>> 2014-06-17 13:10 GMT-04:00 Alejandro Paciotti < >>> [email protected]>: >>> >>>> Dando por sentado que los dos llamamos a esto >>>> <http://eamodeorubio.wordpress.com/2010/07/26/servicios-web-2-%C2%BFque-es-rest/> >>>> un >>>> servicio *REST*, la mayor complejidad podría estar dada por la >>>> autenticación. >>>> >>>> Hace algún tiempo usé con gran satisfacción unas librerías que hizo >>>> un colistero, Pablo Pioli <http://www.coliseosoftware.com.ar/>, que me >>>> permitía abrir una página y bajarla a archivo de texto. >>>> >>>> Luego de identificarte en el sitio donde debes consumir el servicio *REST >>>> *tenés que tener conocimiento de como está hecho para poder consumirlo. >>>> >>>> Un ejemplo podría ser: >>>> >>>> Supongamos que alguien pensó que para saber el saldo de los clientes >>>> el acceso fuese: >>>> >>>> >>>> http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/saldoclientes/json >>>> >>>> Entonces, la respuesta que obtendrías sería un json. >>>> >>>> O bien: >>>> >>>> >>>> http://elsitiodetuproveedordeserviciorest.com.ar/api/clientes/saldoclientes/xml >>>> >>>> Entonces la respuesta sería un XML. >>>> >>>> >>>> No he probado la aplicación de Pablo usando POST, pero también podría >>>> haber algo que puedas consumir desde fox, como por ejemplo: >>>> >>>> >>>> http://elsitiodetuproveedordeserviciorest.com.ar/api/potencialesclientes/nuevo >>>> (y los datos deberían ir por POST) >>>> >>>> Espero haber sido claro. >>>> >>>> Abrazo. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [email protected] >>>> >>>> >>>> El 17 de junio de 2014, 11:29, Alejandro Delgado Jordan < >>>> [email protected]> escribió: >>>> >>>> Alejandro, Para Consumir desde Visual FoxPro >>>>> >>>>> >>>>> >>>>> *De:* [email protected] [mailto:[email protected]] *En nombre de *Alejandro >>>>> Paciotti >>>>> *Enviado el:* lunes, 16 de junio de 2014 17:12 >>>>> *Para:* GUFA List Member >>>>> *Asunto:* [GUFA] Servicio REST >>>>> >>>>> >>>>> >>>>> Consumir con que? >>>>> >>>>> >>>>> [email protected] >>>>> >>>>> >>>>> >>>>> El 16 de junio de 2014, 17:09, Alejandro Delgado Jordan < >>>>> [email protected]> escribió: >>>>> >>>>> Hola: >>>>> >>>>> Alguien sabe donde puedo sacar info y/o ejemplos de como consumir un >>>>> servicio REST.- >>>>> >>>>> Gracias >>>>> >>>>> Alejandro >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> *Por favor, no imprima este mensaje a no ser que sea absolutamente >>>>> necesario. Todos somos responsables por el cuidado del medio ambiente.* >>>>> >>>>> >>>>> *Este e-mail, y cualquier archivo adjunto, fue escrito sólo para la/s >>>>> persona/s o ente/s al que está dirigido, pudiendo contener información >>>>> confidencial o privilegiada. Está prohibido revisar, distribuir, copiar, >>>>> imprimir o hacer cualquier otro uso de este e-mail y sus adjuntos por >>>>> personas o entidades distintas del destinatario. Si recibió este e-mail >>>>> por >>>>> error, por favor contacte inmediatamente al emisor y destruya el >>>>> material. * >>>>> *Según la legislación local vigente, las comunicaciones electrónicas, >>>>> incluyendo el correo electrónico, pueden ser escaneados por nuestros >>>>> sistemas para los fines de seguridad de la información y la evaluación de >>>>> la conformidad con la política interna. El emisor no acepta >>>>> responsabilidad >>>>> por errores u omisiones producidas ni garantiza lo transmitido por este >>>>> medio debido a que puede ser objeto de interpretación, alteración, demora >>>>> u >>>>> otras anomalías.* >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> * Por favor, no imprima este mensaje a no ser que sea absolutamente >>>>> necesario. Todos somos responsables por el cuidado del medio ambiente.* >>>>> >>>>> >>>>> * Este e-mail, y cualquier archivo adjunto, fue escrito sólo para la/s >>>>> persona/s o ente/s al que está dirigido, pudiendo contener información >>>>> confidencial o privilegiada. Está prohibido revisar, distribuir, copiar, >>>>> imprimir o hacer cualquier otro uso de este e-mail y sus adjuntos por >>>>> personas o entidades distintas del destinatario. Si recibió este e-mail >>>>> por >>>>> error, por favor contacte inmediatamente al emisor y destruya el >>>>> material. * >>>>> * Según la legislación local vigente, las comunicaciones electrónicas, >>>>> incluyendo el correo electrónico, pueden ser escaneados por nuestros >>>>> sistemas para los fines de seguridad de la información y la evaluación de >>>>> la conformidad con la política interna. ** El emisor no acepta >>>>> responsabilidad por errores u omisiones producidas ni garantiza lo >>>>> transmitido por este medio debido a que puede ser objeto de >>>>> interpretación, >>>>> alteración, demora u otras anomalías.* >>>>> >>>> >>>> >>> >>> >> >
