Hola, Ale. Un verdadero servicio REST no lo podés resolver a través del navegador, porque por ejemplo, el POST de un formulario no es igual que un POST HTTP a nivel de servicios, y no podés controlar de manera directa los Content Types; salvo que termines escribiendo un montón de JS, caso en el que no es "usar el navegador" solamente.
Saludos, --- Martín Salías <http://CodeAndBeyond.org> <http://CodeAndBeyond.org> 2014-06-18 13:24 GMT-04:00 Alejandro Paciotti <[email protected]> : > De todas formas, yendo a la pregunta original de Jordan: " de como > consumir un servicio REST.-" > > Una respuesta también apropiada sería: *Automatizando un navegador. * > > ¿Cierto o me equivoco? > > Otra respuesta apropiada sería: *depende*... pero esa respuesta es > apropiado para todo... jeje.. > > Gracias por el aporte Martín... > > > > [email protected] > > > El 18 de junio de 2014, 14:20, Alejandro Paciotti < > [email protected]> escribió: > >> Espectacular! >> >> Muchas gracias! >> >> [email protected] >> >> >> El 18 de junio de 2014, 13:57, Martín Salías <[email protected]> >> 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> >>> <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.* >>>>> >>>> >>>> >>> >> >
