none
Servicios web o servicios Rest RRS feed

  • Pregunta

  • Hola, 

    Voy a empezar un proyecto y tengo la duda si utilizar servicios WEB o servicios rest con MVC 4. 

    La cuestión es que los serviciós Rest me parecen geniales pero yo solo necesito un servidor que reciba que funcion ejecutar con N parametros y que devuelva datos en json. 

    Que me recomendáis para empezar el proyecto los webservices clasicos o servicios rest.

    lunes, 18 de febrero de 2013 22:26

Respuestas

  • Buenas!

    No hay ningún incoveniente técnico en que un servicio REST reciba N parámetros. Eso sí, no será REST en el sentido estricto de la palabra.

    REST es más una filosofía y de hecho es, en su definición, independiente de http y de json. Otra cosa es que esas dos tecnologías sean las más usadas, pero se podrían crear servicios REST que no devolviesen json (p. ej. xml) y que funcionasen sobre otros protocolos que no sean HTTP.

    Por otro lado, cuando se habla se servicios web, aunque es un concepto muy genérico (un servicio REST que está en la web no deja de ser un servicio web), por norma general nos referimos a servicios web soap. SOAP si que impone el uso de XML y unos formatos concretos de petición y de respuesta.

    Por lo que, si lo que quieres es "crear un servicio que reciba parámetros y devuelva datos en json" lo puedes hacer perfectamente usando ASP.NET WebApi o incluso si no quieres tener el sistema de enrutamiento basado en verbos http con controladores tradicionales de MVC.

    Saludos!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    martes, 19 de febrero de 2013 12:49

Todas las respuestas

  • Buenas!

    No hay ningún incoveniente técnico en que un servicio REST reciba N parámetros. Eso sí, no será REST en el sentido estricto de la palabra.

    REST es más una filosofía y de hecho es, en su definición, independiente de http y de json. Otra cosa es que esas dos tecnologías sean las más usadas, pero se podrían crear servicios REST que no devolviesen json (p. ej. xml) y que funcionasen sobre otros protocolos que no sean HTTP.

    Por otro lado, cuando se habla se servicios web, aunque es un concepto muy genérico (un servicio REST que está en la web no deja de ser un servicio web), por norma general nos referimos a servicios web soap. SOAP si que impone el uso de XML y unos formatos concretos de petición y de respuesta.

    Por lo que, si lo que quieres es "crear un servicio que reciba parámetros y devuelva datos en json" lo puedes hacer perfectamente usando ASP.NET WebApi o incluso si no quieres tener el sistema de enrutamiento basado en verbos http con controladores tradicionales de MVC.

    Saludos!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    martes, 19 de febrero de 2013 12:49
  • Estimados
    Me uno a la respuesta de Eduard, yo utilizo ultimamente mucho web API con servicios Rest... y a veces no tan Rest(por los parametros que recibe)....pero a lo que voy muy facil de implementar con WebApi

    TIP INTERESANTE: Ademas para comentar que justo mañana hay un webcaste de esta tematica donde podrias preguntar online tus dudas


    Jose. A Fernandez | blog: http://geeks.ms/blogs/fernandezja



    miércoles, 20 de febrero de 2013 5:19
  • Hola, según tu requerimiento de una función que tome parámetros y ejecute, REST cubre perfectamente la necesidad, pero hay que analizar exactamente de qué se trata tu proyecto.

    Actualmente para desarrollar una buena aplicación contamos con la sig. Tecnologías:

    .NET Desktop

    ASP.NET

    ASP.NET MVC

    Servicios Web (ASMX)

    Servicios REST (Web Api o Con WCF RESTFULL API)

    WCF (Múltiples endpoints y configuración mucho más robusta)

     

    Hace unos años en una red local lo que hacíamos era un sistema Desktop que abre conexión con la base de datos vía tcp ip desde la red depsues por cuestiones de seguridad se descubre que para que los datos no pasen en texto plano con algun snifer en la red entonces aunque sea una red local no debes nunca abrir conexión directo desde la aplicación compilada e instalada en cada máquina de los usuarios, te pueden descompilar y ver la cadena de conexión o bien aún que este encriptado con un sniffer la capturan ya desencriptada, la solución era crear servicios web entre el server y la aplicación dektop pero como oran muchos datos el escenario se cubría perfectamente con SOAP  seguridad básica, si queríamos mayor seguridad y la red seria todo Microsoft entonces WCF es la mejor elección, hoy por hoy si el escenario es una aplicación Web, aplicaciones nativas en diferentes dispositivos, entonces REST o SOAP es la mejor elección.

    Según mi punto de vista si yo soy el creador se la aplicación y es una app administrativa por ejemplo yo usaría para el lado del servidor:

    SQL Server 2012

    Entity Framework o NHibernate para acceso a datos como ORM

    Portal en MVC 4

    Y para la aplicación desktop que pudiera ser Linux, Mac o Windows usaría SOAP servicios web con seguridad básica o si acaso integrándole SSL.

    Y las Apps Interface pues ya sería según el lenguaje no importa solo es saber consumir el SOAP.

    Y usaría REST para apps que no contengan toda la lógica de control de una empresa o de operación o admón. simplemente si quiero un cliente para una Tablet, iPhone o una pantalla Samsung para ver reportes o datos no muy grandes entonces REST es lo mejor.

    FIN:

    Si requieres mucho intercambio de datos SOAP es la mejor opción y para datos más cortos y sin estado entonces REST es lo mejor.


    • Propuesto como respuesta Sanccast jueves, 28 de febrero de 2013 9:36
    jueves, 28 de febrero de 2013 9:33
  • Perdona pero algunas cosas no las termino de comprender

    "Cuestiones de seguridad se descubre que para que los datos no pasen en texto plano con algun snifer en la red entonces aunque sea una red local no debes nunca abrir conexión directo desde la aplicación compilada e instalada en cada máquina de los usuarios, te pueden descompilar y ver la cadena de conexión o bien aún que este encriptado con un sniffer la capturan ya desencriptada"

    En una red local no hay ningún problema en acceder a la BBDD directamente desde la aplicación. Es un escenario perfectamente soportado y admitido. ¿Sniffers? ¿En una red LOCAL? Además la cadena de conexión no se transmite por la red. La usa el cliente para abrir la conexión TCP/IP contra la BBDD. Pero no "la va transmitiendo" por ahí. Además en una red LOCAL se suele usar seguridad integrada por lo que ni el login ni el password viajan por la red.

    la solución era crear servicios web entre el server y la aplicación dektop

    Y el servidor web, que se connecta a la BBDD está en???? Ya te lo digo yo: en la propia red LOCAL. Así que según teoría del sniffer y demás, también podríamos ver la cadena de conexión cuando circulase del servidor web al servidor de BBDD. Pero realmente no pasa nada porque, la cadena de conexión no circula por ahí :)

    Que usualmente se use un servicio web para acceder a la BBDD es debido a dos motivos:

    1. Si queremos ofrecer acceso a nuestra aplicación desde fuera de la red, para evitar exponer la BBDD a internet, la "protegemos" tras un servidor web. En caso de ataque solo resulta comprometido el servidor web.
    2. Si vamos a dar soporte a varios usuarios, antes que cada uno de ellos abra una conexión, usamos unas pocas conexiones centralizadas en un solo sitio: el servidor web. De esta manera conseguimos mucha más escalabilidad. Eso aplica, por supuesto, sea una aplicación de internet o de red local (intranet).

    dektop pero como oran muchos datos el escenario se cubría perfectamente con SOAP  seguridad básica, si queríamos mayor seguridad y la red seria todo Microsoft entonces WCF es la mejor elección

    Un par de puntualizaciones ahí: WCF no obliga a que la red sea "todo Microsoft". WCF es una librería que admite varios protocolos de comunicación. SOAP por otro lado es un protocolo que define como dos objetos pueden intercambiarse datos entre sí usando XML. SOAP es altamente extensible y admite montón de protocolos por encima, como toda la família WS-* que ofrecen alta seguridad y fiabilidad. Todos esos protocolos están soportados por WCF. Pero es que WCF no soporta solo WS-* y SOAP. Soporta transmisión binaria y también se pueden crear APIs REST con WCF.

    Si requieres mucho intercambio de datos SOAP es la mejor opción y para datos más cortos y sin estado entonces REST es lo mejor.

    SOAP es un protocolo orientado a RPC, mientras que REST es una filosofia orientada a recurso. Las ventajas de SOAP respecto a REST son que tiene montado un gran conjunto de protocolos addicionales que ofrecen características empresariales (seguridad, fiabilidad, transaccionalidad) mientras que REST suele ser más sencillo y además funciona muy bien con HTTP  (aunque REST es totalmente independiente de HTTP).

    Saludos!


    Eduard Tomàs Blog: http://geeks.ms/blogs/etomas -- Twitter: eiximenis

    jueves, 28 de febrero de 2013 14:09
  • Si en una red local, depende el escenario, yo desarrollo un sistema para una empresa que vende sistemas para hoteles y agencias de viajes en toda la Riviera maya y los mismos empleados son los que quieren "Hackear" el sistema para borrar ventas aplicar descuentos y demás, en una empresa pyme no siempre cuentan con una infraestructura fuerte y con gente de sistemas generalmente lo que quieren es bajar un instalador y con pocos clic instalar tu App y comprarla por internet, es por eso que la App no sabe el tipo de seguridad entre los clientes y el servidor de SQL solo te pregunta la cadena de conexión y si la pones con seguridad integrada o con user y pass pues con un snifer en la red puesto por algún empleado mañoso hay mucho peligro, bueno este desarrollo lo teníamos así desde el 2003 hasta el 2007, en el 2008 con el visual studio 2008 migramos todo a web services y solucionado y corre a la perfección y mucho mejor y la ventaja es que si le das internet al servidor incluso los clientes los apuntas al web service y la aplicación corre por internet, en el 2010 no dijeron que los empleados usaran Windows xp pero el dueño usa mac, entonces como ya teníamos todo en el servidor, únicamente creamos con Mono Develop una interfaz y listo todo OK. Ahora desarrollamos unos módulos para celular y para ipad pero como son módulos no con todo el sistema sino solo con pequeñas partes entonces los andamos creando con rest para poder llegar a más dispositivos.

    Bueno esta es mi experiencia, además cabe mencionar que en un diplomado de WCF por gente certificada por Microsoft me afirmaron que abrir conexión con una base de datos desde un compilado .EXE es MALISIMO. Pero solo es mi punto de vista ustedes saben cómo crean las aplicaciones yo solo platico mi escenario.


    jueves, 28 de febrero de 2013 20:59