Ventajas y Desventajas de SOAP y REST

Ventajas REST

Los servicios Web RESTful son completamente sin estado, ello puede ser comprobado
mediante el reinicio el servidor y comprobando si las interacciones son capaces de
sobrevivir.
Rest es muy ligero, sus respuestas contienen exactamente la información que se necesita
Servicios RESTful proporcionan una buena infraestructura de almacenamiento en caché a
través de HTTP método GET (para la mayoría de los servidores), esto mejorará el
rendimiento, si los datos que devuelve el servicio Web no se altera con frecuencia y no son
de naturaleza dinámica.
Servicios REST son fáciles de integrar con los sitios web existentes y están expuestos a
XML para que las páginas HTML pueden consumir la misma con facilidad. Casi no hay
necesidad de refactorizar la arquitectura de sitio web existente. Esto hace que los
desarrolladores sean más productivos y cómodo, ya que no tendrán que volver a escribir
todo desde cero y sólo hay que añadir la funcionalidad existente.
Desventajas REST

A mi parecer la seguridad es una deficiencia y puede llegar a ser una tarea muy difícil de
implementarla correctamente.
No hay un estándar en sus respuestas por lo que no se definen tipos de datos.
Ventajas SOAP
El Web Services Description Language (WSDL) contiene y describe el conjunto de normas
comunes para definir los mensajes, los enlaces, las operaciones y la ubicación del servicio
Web. WSDL es un tipo de contrato formal para definir la interfaz que ofrece el servicio Web.
SOAP requiere menos código de plumbing code de servicios REST, (es decir, las
transacciones, la seguridad, la coordinación, direccionamiento, la confianza, etc.) La
mayoría de las aplicaciones en el mundo real no son simples y apoyar las operaciones
complejas, que requieren para mantener el estado de conversación y la información
contextual. Con el enfoque de SOAP , los desarrolladores no tienen que preocuparse
acerca de cómo escribir el código de plomería en la capa de aplicación a sí mismos.
Es más seguro debido a que su implementación siempre o la mayoría de las veces se hacen
del lado del servidor.
Soporta varios protocolos y tecnologías, incluyendo WSDL, XSD, SOAP y WS-Addressing.
Desventajas SOAP
Si se desea modificar algo en el servidor esto impacta de una forma negativa en los clientes
ya que ellos realizar varias modificaciones al código
Si no se cuenta con las herramientas correctas, la interpretación puede tornarse demasiado
compleja y difícil.

REST (Representational State Transfer), es un estilo de arquitectura de software dirigidos

a sistemas hipermedias distribuidos como lo es la Web y se refiere específicamente a una
colección de principios (los cuales resumen la forma en que los recursos son definidos y
diseccionados) para el diseño de arquitecturas en red.
Este término es utilizado en su mayoría para describir a cualquier interfaz que transmite
datos específicos de un domino sobre HTTP sin una capa adicional, como lo hace SOAP,
en tal sentido éstos dos significados pueden chocar o incluso solaparse.
Ahora es importante entender que es posible diseñar un sistema software de gran tamaño
de acuerdo con esta arquitectura propuesta sin utilizar HTTP o sin interactuar con la Web,
así como también diseñar una simple interfaz XML+HTTP que no sigue los principios REST,
y en cambio seguir un modelo RPC.
Es de esta forma que es importante remarcar el hecho de que REST no es un estándar, ya
que es tan solo un estilo de arquitectura, pero también está basado en los siguientes
estándares:
• HTTP
• URL
• Representación de los recursos: XML/HTML/GIF/JPEG/…
• Tipos MIME: text/xml, text/html,

SOAP es un protocolo para el intercambio de mensajes sobre redes de computadoras,

generalmente usando HTTP. Está basado en XML, esto facilita la lectura, pero también los
mensajes resultan más largos y, por lo tanto, considerablemente más lentos de transferir.
Existen múltiples tipos de modelos de mensajes en SOAP pero, por lejos, el más común es
el RPC, en donde un nodo de red (el cliente) envía un mensaje de solicitud a otro nodo (el
servidor) y el servidor inmediatamente responde el mensaje al cliente.
Los mensajes SOAP, son independientes del sistema operativo, y pueden transportarse en
varios protocolos de internet como SMTO, MIME y HTTP.
Los procedimientos almacenados son mucho más rápidos. Están dentro de la propia capa
del SGBD, las consultas no tienen que pasar a través de un conector (ODBC / JDBC) y
traducirse, simplemente la llamada al procedimiento y el retorno de resultados, y eso si
deben retornar algo.
Podríamos ver a los procedimientos almacenados como un lenguaje de consultas de bajo
nivel. Son más rápidos, tienes mayor control sobre las operaciones y transacciones...
A nivel de rendimiento siempre son mejores los procedimientos almacenados. Además
piensa que cuando utilizas un procedimiento almacenado los datos sobre los que accede
dicho procedimiento no necesitan salir del servidor de BBDD... Imagínate tener que realizar
cierto calculo con un millón de registros... Si no usaras un procedimiento almacenado el
millón de registros deberían circular por la red des del servidor de BBDD hasta la máquina
que ejecutase la consulta SQL...
Cuando se "compila" un procedimiento almacenado en la base de datos, el optimizador del
motor determina en ese momento el plan de ejecución del mismo, es decir, que índices
debería utilizar, la secuencia de operaciones para ejecutar consultas complejas, etc., etc.
Esta información se guarda junto con el procedimiento, de forma que cuando el usuario lo
invoque, esta información sirva para una rápida y eficiente ejecución del mismo. Esto ocurre
solamente una sola vez, cuando se crea o modifica el procedimiento.
Por otro lado, si lo que pasas al motor son sentencias a manera de texto plano, cada vez
que se ejecute y por cada usuario, se deberá analizar la sintaxis del comando, evaluar el
plan de ejecución, escoger índices, etc., etc. Esto por cada invocación que se haga a esta
sentencia.
Pongamos una aplicación donde (seamos "buen dato" como decimos por acá), solamente
25 usuarios ejecutan una operación intensivamente. Cual crees que le costaría menor
esfuerzo al servidor de datos? Cual crees que responderá y ejecutara mas rápidamente?

La principal ventaja es la performance. Ya que el Procedimiento Almacenado se compila en

el SQL y se ejecuta alli, en cuanto a la cadena de consulta, se compila por cada ejecución
antes de devolver los resultados.
Otra ventaja es la seguridad, ya que es mucho mas fácil que hagan SQL Inyection en
cadenas de consultas que en un SPs La tercer ventaja es el orden. Las cadenas de
consultas son bastante difíciles de leer a primera vista ya que se van armando en base a
variables.
La única desventaja es que si cambias de motor, tendrás que migrar los Spas, pero te
aseguro que se gana muchísimo. Pero ten cuidado de no pasarte al otro extremo de meter
toda la lógica en el motor. No sé qué arquitectura estarás usando para tu App, pero yo te
recomendaría que en el 99% de los casos hagas SP con instrucciones bien simples que
tengan Select, Update, Insert y Updates La lógica y transacciones las manejes dentro de tu
componente en .Net. De esta forma, las reglas quedan en tu App y no en el motor, y utilizas
la potencia del motor. Me guardo un 1% para el caso que realmente haga falta por
cuestiones de performance meter algo más complicado en el motor.

Base de datos En este post, vamos a tratar de explicar las características que hay a la hora
de trabajar con bases de datos entre los motores Myisam vs Innodb, qué ventajas tiene
Myisam frente a Innodb o desventajas, así como las diferencias existentes, muy enfocado
al desarrollo web.

A la hora de abarcar un proyecto web que sobre todo va a tener diversas ejecuciones o
comunicaciones con bases de datos, es muy importante conocer las capacidades del
servidor (alojamiento) que va a gestionar nuestro desarrollo, no solo en capacidad de
almacenamiento sino también en cuanto a versión de software y base de datos que van a
manejarlo.

Los motores más populares y usados en desarrollo web son MyISAM e InnoDB, su correcta
elección definirá como se gestionarán los recursos en cuanto a velocidad, consumo de esos
recursos y calidad de servicio.

Cada proyecto tiene su casuística, a la que debemos prestar atención, conociendo el

número de usuarios que accederán o pueden acceder simultáneamente a realizar altas,
bajas, etc., o bien si tenemos miles de accesos solamente a consulta.

Características de MyISAM:
Se establece por defecto cuando se crea una tabla, salvo que se indique lo contrario.
Soporta transacciones.
Realizar bloqueo de registros.
Soporta un gran número de consultas SQL, lo que se refleja en una velocidad de carga muy
rápida para nuestra web.
Como desventaja, señalamos que no realiza bloqueo de tablas, esto puede ser un problema
si como se ha mencionado anteriormente hay un acceso simultáneo al mantenimiento de
registros por parte de varios usuarios.
Características de InnoDB
Bloqueo de registros. Importante para accesos múltiples al mantenimiento de tablas, es
decir, ejecuciones de sentencias tipo INSERT o UPTATE, estas ejecuciones tienen una
velocidad optimizada.
Capacidad para soportar transacciones e integridad de datos, es decir previene el alta de
datos no adecuados.
Aplica las características propias de ACID (Atomicity, Consistency, Isolation and Durability),
consistentes en garantizar la integridad de las tablas.
Como desventaja, marcamos que al ser un tipo de motor que define un sistema más
complejo de diseño de tablas, reduce el rendimiento en velocidad para desarrollo que
requieren de un elevado número de consultas.

Ventajas: MyISAM vs InnoDB

InnoDB
Soporte de transacciones
Bloqueo de registros
Nos permite tener las características ACID (Atomicity, Consistency, Isolation and Durability:
Atomicidad, Consistencia, Aislamiento y Durabilidad en español), garantizando la integridad
de nuestras tablas.
Es probable que si nuestra aplicación hace un uso elevado de INSERT y UPDATE notemos
un aumento de rendimiento con respecto a MyISAM.
MyISAM
Mayor velocidad en general a la hora de recuperar datos.
Recomendable para aplicaciones en las que dominan las sentencias SELECT ante los
INSERT / UPDATE.
Ausencia de características de atomicidad ya que no tiene que hacer comprobaciones de
la integridad referencial, ni bloquear las tablas para realizar las operaciones, esto nos lleva
como los anteriores puntos a una mayor velocidad.
Una (casi) desconocida de las funcionalidades de MySQL, a partir de su versión 3.23.23 es
"Full-text" , que permite realizar búsquedas dentro de un campo a partir de una cadena de
caracteres.
Habitualmente, un método de búsqueda sencillo dentro de una tabla pasaba por utilizar
LIKE:

SELECT texto FROM artículos WHERE texto LIKE '%$palabra%'

El problema aparecía cuando en vez de una sola palabra eran varias las que había que
buscar: Si "$palabra" equivalía, por ejemplo, a "dreamweaver ultradev", una frase dentro de
los textos almacenados que fuera "dreamweaver y ultradev" no devolvería resultados (por
culpa de la "y").

Para esto sirve Full-text: MySQL se encargará de comparar la cadena que le pasemos con
los contenidos de la BD y devolver resultados aproximados. Suena bonito, pero tiene
algunas limitaciones (justificadas):

No devolverá resultados si la palabra aparece demasiadas veces en los registros: si todos

nuestros registros (o más del 50%, para ser más exactos) tienen la palabra "dreamweaver",
no devolverá resultados. ¿Por qué? Esta función está pensada para tablas con muchos
registros y no tendría sentido devolverlos todos: ¿es interesante devolver 5.000 resultados
a una búsqueda?
Por la razón anterior, la consulta omitirá palabras demasiado comunes, como preposiciones
y artículos (de, con, a, el)...

¿Qué necesitamos para utilizar Full-text?

Lo primero, que MySQL sea de una versión superior a la 3.23.23.
Que el campo de la tabla en que vamos a buscar sea del tipo TEXT
Con estos 2 requisitos, lo primero que necesitaremos será indicarle a MySQL que queremos
modificar el campo para que acepte esta función. En nuestro ejemplo vamos a utilizar una
sencilla tabla, llamada "artículos", que tiene estos campos.

id articulo

titulo

texto

Podemos utilizar cualquiera de los IDE's disponibles para MySQL (MySQLFront ó

PHPMyAdmin son válidos), para pasarle a la BD esta sentencia SQL:
ALTER TABLE articulos ADD FULLTEXT(texto);

Si lo hemos realizado correctamente, MySQL nos devolverá el OK.

Con la tabla preparada, llega la hora de aprender cómo se pasan las consultas, ya que no
basta con SELECT: deberemos utilizar además MATCH (campo) AGAINST (cadena). En
nuestro ejemplo:

SELECT titulo, texto FROM articulos WHERE MATCH (texto) AGAINST ('$palabras')

Traducido: seleccionar los campos "titulo" y "texto" de "artículos", filtrando donde haya
coincidencias en el campo "texto" para la variable "$palabras".

¿No parece difícil, no?, pues aún hay más: MySQL nos puede devolver un número que
indica el valor de coincidencia en cada registro (llamado habitualmente "SCORE" en
muchos sitios). No es un valor en porcentaje, y puede variar desde casi 0 (cero) hasta más
de 4 según los cálculos realizados por MySQL). Es útil para ordenar los resultados por
orden de coincidencia. Utilizarlo es un poco más complicado, pero no mucho: sólo
tendremos que utilizar 2 veces MATCH... AGAINST. La consulta sería:
SELECT titulo, texto, MATCH (texto) AGAINST ('$palabras') AS coincidencia
FROM articulos
WHERE MATCH (texto) AGAINST ('$palabras')
ORDER BY coincidencia DESC

Si tenemos una tabla con nuestras noticias donde hay un título y un cuerpo principal de la
nota, titulo y cuerpo, primero hay que asegurarse que sean Varchar o TEXT, no usar BLOB
para esto, no sirve.
Luego hay que crear el índice:
ALTER TABLE notas ADD FULLTEXT (titulo, cuerpo);

Ahí se crea el índice para la búsqueda, esto puede ocupar un poco más de espacio pero lo
importante se ve en el resultado de la búsqueda. Más rápida y eficiente que un Like,
simplemente funciona como un buscador y no como una comparación sencilla y costosa
como el like.
Buscamos así:

SELECT * FROM notas

WHERE MATCH (titulo, cuerpo) AGAINST ('Paleta')

Donde 'Paleta' es nuestra palabra de búsqueda nos podrá traer inclusive frases o más de
una palabra (el like se muere si le hacen eso)

Pero si además quieren ordenarlo por "rating" u orden de importancia de la búsqueda:

SELECT *, MATCH (titulo, cuerpo) AGAINST ('Paleta') as Score

FROM notas
WHERE MATCH (titulo, cuerpo) AGAINST ('Paleta')
ORDER BY Score DESC
(obviamente nunca usen *, ahí pongan los campos que van a usar)

Score tiene un valor que no se bien como se calcula pero nos da un orden coherente de lo
que se encontró tal cual hacen algunos buscadores que imprimen un porcentaje o un valor
de "acierto"

Inconvenientes:

El límite de búsqueda está configurado en el MySQL y por lo general es de 4 caracteres,

así que si quieren buscar algo simple como... PHP! no lo van a poder encontrar y no va a
emitir ningún resultado. Sucede eso con las búsquedas demasiado simples que resulten en
un 50% de las posibilidades de encontrar, directamente da resultado nulo. Así que ese es
el único detalle en contra pero a favor que busca muy rápido y más eficientemente además
de que el resultado es el que queríamos.