Qué es un API Rest
Clase 83 de 96 • Curso Definitivo de Android 2016
Contenido del curso
Creando nuestro entorno de desarrollo
Básicos de Android
Creando Platzigram
- 20

Configurando nuestro tema Material
16:41 min - 21

Widgets de Material Design
10:39 min - 22

Maquetando nuestras vistas del proyecto
14:21 min - 23

¿Qué es un Activity?
22:21 min - 24

Maquetando nuestros Activities
25:19 min - 25

Internacionalización de Textos
11:20 min - 26

Rised button
09:54 min - 27

EditText con Material Design
11:26 min - 28

Terminando el Home de nuestra aplicación
09:17 min - 29

Toolbar
20:30 min - 30

Intents
12:29 min - 31

CardView
07:51 min - 32

Analizando nuestra vistas
07:48 min - 33

Maquetando nuestro CardViewd
29:35 min - 34

Introducción a Fragments
08:37 min - 35

Creando nuestros fragments
21:46 min - 36

Fragments en nuestro BotttomBar
19:13 min - 37

¿Cómo funciona un RecyclerView?
11:44 min - 38

Implemententando RecyclerView
28:43 min - 39

Picasso
05:54 min - 40

Analizando nuestra vista
10:04 min - 41

Collapsing Toolbar Layout, AppBarLayout
26:32 min - 42

Onclick Listener en RecyclerView
11:06 min - 43

Implementando la vista de perfil
15:07 min - 44

Comportamientos dependientes en Material Design
22:48 min - 45

Transiciones en Android.
16:32 min
Conclusiones
Continuando con Platzigram
Arquitectura en Android
- 52

¿Por qué se debe implementar una Arquitectura en Android?
06:40 min - 53

Principios SOLID en Android
05:46 min - 54

¿Qué es y por qué implementar MVP en Android?
05:38 min - 55

MVP en Android un ejemplo sencillo
32:06 min - 56

¿Qué es la arquitectura limpia? Clean Architecture
08:38 min - 57

Platzigram con Clean Architecture creando la entidad Login
14:21 min - 58

Integrando un Presenter e Interactor a Platzigram
10:44 min - 59

Creando un Repository en Platzigram
15:09 min
Accediendo al Hardware en Android
Configuración de Firebase en Android
Gradle en Android
Firebase Authentication en Android
- 67

Cómo funciona Firebase Authentication en Android
13:00 min - 68

Firebase Authentication Correo y Contraseña en Platzigram
21:34 min - 69

Sign In y Sign Out Correo y Contraseña en Platzigram
11:43 min - 70

Configurando Facebook Developers
10:53 min - 71

Implementando Facebook Login en Platzigram
14:00 min - 72

Manejando una sesión en Facebook con Android y Firebase
07:57 min
Almacenamiento en Android
Menús en Android
Firebase Storage en Android
Logcat de Android y Crash Reporting de Firebase
Conexión a Servicios Web con Retrofit en Android
Trabajando con otra API, Medium
Seguridad en Android
Animaciones en Android
Android Things
Publicación en el PlayStore
Contenido complementario
En el artículo anterior te hablé de una capa que se encuentra externa a nuestro dispositivo móvil pero con la cual tenemos que interactuar constantemente, ¿ya recordaste cuál? El Web Server, quien en su interior tiene albergado un software que se encarga de gestionar tus solicitudes y devolverte la información que necesitas en un formato adecuado.
Hoy quiero hablarte de ese software que vive dentro del Web Server y mostrarte cómo está construido para que entendamos el papel que juega en la comunicación de nuestro dispositivo con los datos almacenados. Este software es también conocido como un Backend, que puede estar construido en diversidad de lenguajes que para quienes trabajamos del lado de la aplicación podríamos ni siquiera enterarnos de cuáles son, y siendo: Python, Ruby, JavaScript, Java, algunos de los más populares.
Para que nosotros como desarrolladores móviles podamos entender y comunicarnos con este software Backend necesitamos estar de acuerdo con el desarrollador en las reglas que debe tener para poder leer/insertar/actualizar/eliminar un registro y nos dé una respuesta de vuelta. Bueno, te cuento que a veces no tendremos la oportunidad de hablar con el desarrollador, es más, a veces ni si quiera podrás conocerlo de ninguna forma, pero aún así necesitas entender cómo funciona el software que procesará tus solicitudes.
La única forma de lograr un standard en la comunicación con el backend es implementar cierta arquitectura o diseño que sea homogénea y persistente todo el tiempo. Precisamente esto se logra con un ++API REST++, es un tipo de arquitectura de desarrollo web que significa Representational State Transfer y quiere decir que tendremos una transferencia de datos representada por un estado en particular que aplicará siempre. Es decir siempre que queramos ejecutar un tipo específico de solicitud (leer/insertar/actualizar/eliminar un registro) esta siempre será representada por un estado. Pero para completar el concepto API Rest nos falta definir ++API++; un API será un conjunto de métodos o acciones que se enfocan en un objeto en particular, por ejemplo, si analizamos todas las acciones que podemos ejecutar al objeto profesor, podrían ser:
- Leer un profesor
- Insertar un profesor
- Actualizar uprofesor
- Eliminar un profesor
A este conjunto de acciones que afectan a un objeto en particular se les llama API y como ves esta basado en POO (Programación Orientada a Objetos), y todas estas acciones se pueden aplicar a cualquier objeto.
Si unimos todo lo que acabamos de aprender, un ++API Rest++ significará un conjunto de métodos/acciones que se pueden aplicar a un objeto representadas por un estado en particular.
¿A qué tipo de estados particulares me refiero y cómo los puedo representar? Bueno precisamente esta es la parte donde te hablo de los ++verbos HTTP++, los verbos son las acciones que puede tener el objeto pero tienen que ser representadas por algo que el protocolo HTTP entienda, por ejemplo: si queremos leer un profesor el verbo HTTP será GET, mira los demás:
- Leer un profesor GET
- Insertar un profesor POST
- Actualizar un profesor PUT(antes) / PATCH(ahora)
- Eliminar un profesor (DELETE)
Probablemente solo habías escuchado del método GET y POST pues son los más comunes, pero los demás realmente existen.
Entonces, el estándar de comunicación que debe tener el software backend debe ser idealmente un API Rest, para que aunque no tengamos el gusto de conocer al programador sabremos que cumplirá las siguientes reglas:
-
La base de las acciones serán siempre objetos.
-
Siempre tendremos un API definido para cualquier objeto o sea insertar/leer/actualizar/eliminar en inglés sería Create/Read/Update/Delete seguramente has visto algo como CRUD.
-
Las acciones serán definidas por un estado o un verbo HTTP (POST/GET/PATCH/DELETE).
Por lo tanto siguiendo estas reglas si nos concentramos en el objeto profesores, yo podré ejecutar las siguientes acciones con esta url base ++https://platzi.com/profesores++ (Los enlaces de acontinuación son usados solo para ejemplificar)
- GET https://platzi.com/profesores Leer todos los profesores
- GET https://platzi.com/profesores/1 Leer el profesor con identificador 1
- POST https://platzi.com/profesores Insertar un profesor
- PUT(antes) / PATCH(ahora) https://platzi.com/profesores/1 Actualizar un profesor
- DELETE https://platzi.com/profesores/1 Eliminar un profesor
Donde cada url de este tipo en conjunto con su método se llamará ++Endpoint++.
Esto que te acabo de mostrar son tan solo ejemplos básicos que nos ayudan a entender más todos estos conceptos, en general todas las API’s deben trabajar con estos puntos que platicamos, si quieres saber más sobre APIs Rest te recomiendo leer este artículo que se encuentra en el blog de Platzi.
Quiero que entres a este enlace que habla sobre el API de Medium, aprende todo sobre ella e identifica todos los elementos que acabamos de platicar, cuentame aquí en los comentarios lo que aprendiste del API de Medium.
En los siguientes artículos te enseñaremos a implementar esta API en tus aplicaciones Android con Retrofit.