Вы находитесь на странице: 1из 2

Hay cosas muchas mas copadas un ejemplo chiquito.

Repaso de REST

Rest es un estilo de arquitectura se basa en una representación del recurso es cliente servidor es
backend. Trabaja y comunica cuando quiere hacer cache se basa en un proxy no es que se queda
solo en la información cache en el backend.

Es una capa mas grande de lo que vamos a ver de lo que es GraphQL reposa mucho en los estatus.

Estatus 200, 300, 400 y 500

Los errores que están todo bien.

Después tengo los verbos.

Cliente o clientes.

Quiero una consulta quiero insertar datos.

Alguno insertó con REST y fueron respetando todas esas cosas y venían con un request y response
otro tipo.

REST descansa mucho sobre URL siempre trabajo sobre ese recurso y en base al verbo y una
pregunta sobre el query String tiene un mensaje descriptivo del backend.

Yo le puedo decir. Si yo tengo un insert aquí lo puedes consultar normalmente esas partes no las
hacemos mucho después si estoy en una paginación estoy haciendo una consulta sobre una grilla
tenes mas adelante o una grilla aca viene algo de no hay dudas.

Paso de REST

URL complejas – GET

Tales propiedades del libro. Libro complejo a mi me parece importante esto

Pensando en API Rest y GraphQL

REST

- Pienso en recursos
- Operaciones y consultas sobre más recursos | HTTP Verbs / Matchok
- Cache
- Jerarquía en consultadas en tu RB

Mutaciones

Subscripciones
Y mutaciones también hago queries pienso en lo que quiere el cliente en lo que el cliente en como
lo necesita y cómo quiere. Lo que le comparte de Rest Rest es una representación de datos la
verdad puede haber cualquier cosa.

Y a veces es un poquito más puedo inventar cálculos un monton de cosas… es común cuando
están migrando que GraphQL le pegue a un Rest lo fundamental acá es que pienso en lo que
quiere el cliente que tenga una interacción.

Backend cuando yo empiezo a pensar en GraphQL mi archivo de esquemas puede llegar a crecer
muchísimo sino es ilegible para empezar a desarrollar y meter mano.

Comparando API Rest y GraphQL (analizando porqué GraphQL)

API Rest

- Métodos / Verbos

Get | Post | Delete | Put | Patch

- Endpoints
- Recursos
- Un Querydoing y tody dues.

GraphQL

- Post is GET

Query | Mutation | Subscription

- Un solo endpoint
- Schema / types
- Query Language
- Pensar en lo que el cliente va a querer
- Consultas sobre los schema y los tipos definidos.

En REST puedo llegar a tener mucho EndPoint en GraphQL tengo solo un endpoint puedo llegar a
ser una desventaja o mis recursos porque capaz que un recurso representa a varias entidades y
puedo llegar a tener muchos ENDPOINT casi los ENDPOINTS grandes cambian a una sola vista.

Una vista puede bueno yo tengo un endpoint… termina de darle al endpoint o le estoy
devolviendo un monton de información. Del recurso con GraphQL bien en restfull pero podría
llegarlo a limitar dentro de una gran cantidad de campos o caemos también en pensar en un
montón de tipo de get en rest y ahí si estoy ensuciando un poco y ingreso GraphQL.

Вам также может понравиться