{"id":14613,"date":"2023-07-12T11:10:49","date_gmt":"2023-07-12T18:10:49","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=14613"},"modified":"2025-06-13T19:56:50","modified_gmt":"2025-06-14T02:56:50","slug":"mobile-developers-is-rest-keeping-you-up-at-night","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/mobile-developers-is-rest-keeping-you-up-at-night\/","title":{"rendered":"Desarrolladores m\u00f3viles: \u00bfLe quita el sue\u00f1o REST?"},"content":{"rendered":"

RE<\/b>presentaci\u00f3n <\/span>S<\/b>tate <\/span>T<\/b>ransfer, com\u00fanmente conocido como \"REST\", describe un est\u00e1ndar para la comunicaci\u00f3n program\u00e1tica con servicios de datos backend a trav\u00e9s de la web.<\/span><\/p>\n

Una API REST es una interfaz de programaci\u00f3n que utiliza peticiones HTTP para POST (crear), GET (leer), PUT (actualizar) y DELETE datos (conocidas como \"operaciones CRUD\") a trav\u00e9s de un punto final URL b\u00e1sico similar a <\/span>https:\/\/sample.com\/api\/products<\/span><\/i>. Los desarrolladores crean aplicaciones que interact\u00faan con la API mediante solicitudes HTTP al punto final.<\/span><\/p>\n

Piense en los puntos finales de la API REST como encapsulaciones de consultas que se exponen para que los desarrolladores interact\u00faen con una fuente de datos. La abstracci\u00f3n de la complejidad hace que el uso de REST sea f\u00e1cil: es s\u00f3lo una URL, pero ten en cuenta que s\u00f3lo las consultas que los autores de la API han pensado y expuesto est\u00e1n disponibles para las masas, la manipulaci\u00f3n de datos m\u00e1s all\u00e1 de esas consultas requiere programaci\u00f3n.<\/span><\/p>\n

Debido a su sencillez, y al hecho de que casi todas las soluciones de software importantes ofrecen acceso REST, aprovechar las API REST para los datos se ha convertido en un enfoque popular para el desarrollo de aplicaciones web.<\/span><\/p>\n

\u00bfPor qu\u00e9 REST en primer lugar?<\/span><\/h2>\n

Las API REST son una gran opci\u00f3n para muchas aplicaciones, especialmente las menos complejas con requisitos b\u00e1sicos de obtenci\u00f3n y actualizaci\u00f3n de registros.<\/span><\/p>\n

Por ejemplo, una aplicaci\u00f3n que muestre \"ubicaciones cercanas\" de un minorista podr\u00eda pasar las coordenadas de ubicaci\u00f3n del usuario a un punto final REST como <\/span>\"<\/span>https:\/\/sample.com\/api\/locations\/?=___<\/span><\/i>\", que devuelve las direcciones de las tiendas en un radio determinado de esa ubicaci\u00f3n. Toda la informaci\u00f3n que la aplicaci\u00f3n necesita para la funci\u00f3n \"tiendas cercanas\" se proporciona a trav\u00e9s de un sencillo bot\u00f3n <\/span>GET<\/span><\/em> llamada. Por este tipo de razones, REST es bueno cuando las necesidades de datos de la aplicaci\u00f3n pueden satisfacerse con un acceso general a las entidades.<\/span><\/p>\n

Pero si tu aplicaci\u00f3n requiere m\u00e1s l\u00f3gica para el manejo de datos, como las que modifican con frecuencia entidades como usuarios, cuentas o inventarios, probablemente necesites un control m\u00e1s granular de los datos que el que muchas API REST pueden proporcionar por s\u00ed solas. Esto fuerza a los desarrolladores a situaciones en las que tienen que codificar en torno a las limitaciones de REST para obtener los datos precisos que la aplicaci\u00f3n requiere, haciendo cosas como filtrar y combinar datos en el c\u00f3digo, lo que lleva m\u00e1s tiempo e inevitablemente erosiona la eficiencia de la aplicaci\u00f3n.<\/span><\/p>\n

Adem\u00e1s, como la aplicaci\u00f3n es m\u00f3vil, tambi\u00e9n hay que lidiar con problemas de conectividad cuando se depende de API REST a trav\u00e9s de la web para obtener datos, una tarea nada trivial.<\/span><\/p>\n

Aqu\u00ed es donde probablemente empezar\u00e1s a encontrarte con los puntos d\u00e9biles de la API REST...<\/span><\/p>\n

Puntos d\u00e9biles del uso de REST<\/span><\/h2>\n

Falta de validaci\u00f3n de esquemas y tipos de datos<\/span><\/h3>\n

Cada API REST se construye espec\u00edficamente para las entidades que expone y, por tanto, no existe un protocolo est\u00e1ndar para la validaci\u00f3n de esquemas o tipos de datos esperados. Esto significa que los desarrolladores deben ser conscientes de estos detalles y solucionarlos, o sufrir las consecuencias en forma de inestabilidad y fallos de la aplicaci\u00f3n.<\/span><\/p>\n

Por ejemplo, podr\u00eda enviar una solicitud de una lista de productos utilizando \"<\/span>GET \/productos<\/span><\/em>\", pero no hay forma de validar que el endpoint existe. Esto es especialmente problem\u00e1tico cuando se utiliza un endpoint que estaba disponible en versiones anteriores de una API que ya no est\u00e1 disponible en versiones m\u00e1s recientes.<\/span><\/p>\n

E incluso si el endpoint existe, no hay forma de validar los detalles de la entidad que devuelve. Por ejemplo, un producto determinado de la lista de productos devuelta puede haber sido modificado o eliminado por otro cliente desde que se solicit\u00f3 la lista.<\/span><\/p>\n

Los tipos de datos tambi\u00e9n pueden diferir para los mismos datos entre endpoints, dependiendo de c\u00f3mo se haya implementado cada uno. Por ejemplo, estas dos solicitudes de punto final devolver\u00e1n los mismos datos, pero con ligeras diferencias:<\/span><\/p>\n\n\n\n\n\n
Solicitar<\/b><\/td>\nRespuesta<\/b><\/td>\n<\/tr>\n
GET \/productos\/123<\/span><\/td>\n{
\n<\/span>\u00a0Precio: 10,95
\n<\/span>\u00a0Divisa: \"USD\"
\n<\/span>}<\/span><\/td>\n<\/tr>\n
GET \/inventario\/producto\/123<\/span><\/td>\n{
\n<\/span>\u00a0Precio: \"10.95\",
\n<\/span>\u00a0Divisa: \"USD\"
\n<\/span>}<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

En este ejemplo, una respuesta devuelve el precio del producto como un double, y la otra devuelve el precio del producto como una cadena. Estos son los tipos de datos que pueden hacer que las aplicaciones se vuelvan inestables o se bloqueen.<\/span><\/p>\n

Transformaci\u00f3n de datos de ida y vuelta<\/span><\/h3>\n

Manejar tipos de datos requiere un ciclo interminable de transformaci\u00f3n de los datos de la entidad en lo que espera cada extremo de la conexi\u00f3n. Por ejemplo, para que una aplicaci\u00f3n aproveche una API REST, el flujo de comunicaci\u00f3n ser\u00eda algo parecido a esto:<\/span><\/p>\n\n\n\n\n\n\n\n
\n
    \n
  1. Definir modelos de datos de entidades<\/span><\/li>\n<\/ol>\n<\/td>\n
\n
    \n
  • Definir modelos de datos en c\u00f3digo nativo<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
2. Serializar datos en JSON<\/span><\/td>\n\n
    \n
  • Convertir objetos nativos en JSON<\/span><\/li>\n
  • Formatee entidades de datos nativas en una estructura que su punto final REST espera<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
3. Transporte por HTTP<\/span><\/td>\n\n
    \n
  • Codificar datos como cadena JSON<\/span><\/li>\n
  • Codificar cadena JSON como datos de formulario HTTP multiparte<\/span><\/li>\n
  • Enviar una solicitud POST<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
4. Decodificaci\u00f3n de datos en backend<\/span><\/td>\n\n
    \n
  • Descodificar datos POST<\/span><\/li>\n
  • Decodificar cadena JSON<\/span><\/li>\n<\/ul>\n<\/td>\n<\/tr>\n
5. Operaciones CRUD en la base de datos<\/span><\/td>\n\n