Swift 3: Integración con tecnologías backend

Servicios web: conceptos básicos

¡Prueba gratis durante 10 días

nuestros 1198 cursos !

Prueba gratis Mostrar modalidades de suscripción
En este video vamos a analizar todos aquellos conceptos y elementos básicos que necesitamos manejar para poder identificar qué necesitamos saber a la hora de elaborar nuestros primeros servicios web.

Transcripción

¡Perfecto! Ya estás prácticamente listo para comenzar con los servicios. Ya definiste muy bien cómo está tu cliente, cómo va a funcionar el flujo en tu aplicación y, ahora, necesitas saber cómo vas a entregar los datos. Aunque esto es un flujo que estamos tomando desde la perspectiva del cliente móvil, no es necesariamente la única estrategia. ¿Cómo puedes hacerlo? Puedes hacer primero el API, después el "back-end" y por último el cliente. O primero el cliente, luego el "back-end" y finalmente documentas el API. En realidad, hay muchas estrategias. Tú ya tienes definido el cliente, así que lo que falta es moverte al lado del "back-end". Y para eso necesitas entrar con algunos conceptos: los conceptos básicos. Estos conceptos pueden convertirte en un "Full Stack Mobile Developer". Alguien capaz de hacer "back-end" básicamente, hacer cliente, colocar en producción diseñar el API, generar las pantallas y guardar los datos en los clientes móviles. Así que esto es muy poderoso. Le ponemos muchísima atención a cada uno de los conceptos. Primero lo básico. ¿Qué necesitas saber para empezar a trabajar con el "back-end"? Lo primero, quién es el cliente. El cliente es un concepto que se refiere a todo aquel que está consultando, a todo aquel que no centraliza los datos. Por ejemplo, un cliente de iOS es un cliente. Un cliente en un iPad o en un iPhone es un cliente. Por ejemplo, si tienes una aplicación en escritorio también puede ser un cliente. Pero puede confundirse con el servidor, y te diré por qué. Un servidor, como sabes, es también un ordenador. De hecho, tu ordenador de desarrollo local puede ser un servidor web. Pero lo importante es saber dónde estás concentrando los datos y quién está disponible siempre para servirlos. Por lo regular, los clientes solamente se conectan, hacen la consulta, la muestran y se cierran. Pero el servidor está siempre conectado para cualquiera que lo consulte. Pero con los servicios push el cliente siempre está esperando si hay alguien que le tenga que enviar algún mensaje. Eso puede confundirte un poco, pero no te preocupes. Solamente ten en cuenta esto: el cliente es el que regularmente no tiene centralizado los datos de todo los usuarios. Y el servidor sí los tiene centralizados en una base de datos, o en un conjunto de servicios o herramientas. El cliente será el responsable de manejar un usuario a la vez y el servidor será el responsable de manejar miles de usuarios a la vez. Ahora, ¿qué es un servicio web? Un servicio web es básicamente una estructura o una petición en la que envías y recuperas datos. El servicio web no necesariamente está hecho en JSON, XML O TXT. Puede tener el formato que quieras. Hay muchos tipos de servicios web, muchas estructuras, y estándares para definirlos. No creas que es algo nuevo. Es algo que llevamos muchos años utilizándolo. El tema es que, en los últimos diez años, lo utilizamos muchísimo más porque todos nuestros clientes móviles ya empezaron a utilizar web de manera intensiva. ¿Qué es un API (inglés) o API? El API es en realidad una descripción de cómo los servicios web funcionan. Es básicamente lo que el programador del "back-end" expone a los clientes. Lo que se está transfiriendo o lo que necesitas enviar para que te entregue una respuesta correcta. Este API cuando es remoto establece un lenguaje y una estructura para que se pueda parsear o comprender tanto del lado del cliente como del lado del servidor. También existen las API de bibliotecas por ejemplo, o de "frameworks". "Cocoa Touch", por darte un ejemplo, ofrece un API, pero si te fijas, en realidad, no hay una comunicación con Internet de por medio. En el caso de una unión con un servidor de "back-end", el API sí tendrá conceptos y protocolos muy específicos de Internet para transformación y pase de mensajes a través de la red. Otra cosa, ¿qué es un "request"? Un "request" es lo que hace el cliente. El cliente genera un documento, —texto plano—que tiene un formato de HTTP, se lo pasa se lo pasa al protocolo de TCP IP y lo manda por Internet. Ahora, ese "request" puede tener muchas formas. Pero, por lo regular, el contenido o el contenido que vamos a utilizar lo generamos en formato JSON. El formato JSON es como el formato de XML o CBS El caso es que es un formato. Es una forma de describir objetos óptima y rápida de parsear para los móviles. Es aún más óptima que XML. Así que JSON es el formato que nosotros utilizaremos, aunque no es el único. Y por otro lado, el "response". El "response" o respuesta es lo que el servidor nos entrega de vuelta. Nosotros le hacemos una petición en un formato JSON y el servidor nos entrega una respuesta también en formato JSON. ¿Cómo funciona? El "response" cuando llega y recibe el paquete que le enviaste en el "request" sobre TCP IP, el servidor lo abre y dice, "¡Ah! Este es una petición de HTTP", lo desenvuelvo para traer los encabezados y su contenido y lo proceso, hago lo que necesite, ya sea evaluar al usuario, devolver algunos valores o simplemente decirte que todo está bien. Lo que haces es serializar esa respuesta en un JSON y se la entregas otra vez al cliente. Otros conceptos importantes son la diferencia entre Internet y web. Básicamente, Internet es todo lo que está encima de TCP IP y web es todo lo que está encima del protocolo HTTP. Ahora, el protocolo HTTP es lo que nos permite establecer la comunicación entre el cliente y servidor de una manera más sencilla. ¿Podrías utilizar otros protocolos, definir tu propio protocolo para comunicarte con el cliente? Puede ser, pero hay en realidad muchísimas cosas ya encima de HTTP, que harán muy sencilla la comunicación entre cliente y servidor. Ahora, el servidor web es un servidor que nos ayuda a establecer la comunicación entre HTTP por Internet. ¿Cómo funciona esto? El "Web Server" lo que tiene es una instancia de una "engine" o un Apache que deserializa todas las peticiones y las pasa a un "Application server". El "Application server" es tu aplicación hecha en Java en Ruby on Rails, en Django, en Note, en lo que tú quieras. Ese es tu "Application server", en donde está toda tu lógica. Por otro lado, tenemos también el "Cloud". El "Cloud" es el conjuntos de servidores que se encuentran conectados a la red todo el tiempo. Estos pueden o no tener servicios expuestos y esa es una de las principales razones del "Cloud". Puedes tener servicios como HTTP, FTP, SCH entre otros. XML y JSON son los formatos que puedes utilizar en tus peticiones y en tus respuestas. "RESTful" es la técnica que utilizaremos para hacer las peticiones entre el cliente y el servidor. Los recursos son todo aquello que obtienes del servidor, como por ejemplo, un usuario. Un usuario y la información de estructura de ese usuario básicamente es un recurso. Todas las peticiones tienen un encabezado y un cuerpo. Los encabezados pueden ser varios, se definen como llaves y valores y son muy sencillos de establecer. El cuerpo es básicamente en dónde va a ir el formato XML o JSON. Necesitas serializar cada uno de estos cuerpos. Tendrás una instancia en Swift de algún objeto de alguna clase, necesitas serializarla a un objeto JSON y enviarla. Y cuando regrese tendrás que parsearla. Ellos te van a devolver o, mejor dicho, el servidor te va a devolver un objeto JSON lo vas a parsear y lo vas a convertir en un objeto de dominio. Estos son los conceptos más importantes. Sé que son muchísimos, pero poco a poco los irás asimilando y encontrando las diferencias entre cada uno para tus aplicaciones, identificándolos en documentos y en otro tipo de referencias que puedas tener en este curso.

Swift 3: Integración con tecnologías backend

Aprende a vincular tus aplicaciones web creadas con Swift 3 con el servidor, comienza a enviar información entre ambos y aprovecha esto al máximo dentro de tus sistemas.

3:08 horas (27 Videos)
Actualmente no hay comentarios.
 

Este curso video2brain está disponible como descarga y para ser visualizado online. ¡Pero no hace falta que decidas entre las dos opciones! Al comprar el curso, disfrutarás de ambas posibilidades.

La descarga te permite ver las lecciones sin estar conectado/a a internet y supone una navegación fácil y ágil entre capítulo y capítulo. Si vas a trabajar en diferentes ordenadores o si no quieres descargarte el curso completo, entra en la web con tus datos de acceso y disfruta directamente de tus vídeos online. Te deseamos que disfrutes de este curso y te resulte de mucha utilidad.

Estamos a tu disposición si tienes cualquier tipo de duda o pregunta.