Sto scrivendo un articolo su REST tradizionale vs GraphQL.
Tuttavia, dopo aver fatto alcune ricerche su REST (non solo su un'implementazione specifica di REST), ho iniziato a vedere che GraphQL in realtà si attiene alle stesse regole di REST, con 1 eccezione minore.
IMPORTANTE: sto parlando delle specifiche REST attuali. Non sto parlando solo di un'implementazione tradizionale di REST.
I principi REST sono descritti qui:
Questi sono:
- Architettura del server client
- apolidia
- Cache
- Sistema stratificato
-
Interfaccia uniforme
- Identificazione delle risorse nelle richieste
- Manipolazione delle risorse tramite le rappresentazioni
- Messaggi di auto-descrizione
- Hypermedia come motore dello stato dell'applicazione (HATEOAS)
GraphQL soddisfa banalmente i criteri di Client Server Architecture "," Statelessness "e" Layered System ".
È possibile realizzare un'implementazione GraphQL per soddisfare la cacheability , applicando che id è richiesto per ogni risorsa (si veda: link )
Che lascia " Uniform Interface ", che ha 4 sub-constraint:
Identificazione della risorsa nelle richieste
Individual resources are identified in requests.
GraphQL soddisfa Identificazione delle risorse nelle richieste , in quanto non vi è alcuna menzione che le risorse debbano essere nell'URL o nell'uso dei verbi HTTP.
Pertanto entrambi:
GET /books?fields=title
e
POST /graphQL
{
books {
id
title
}
}
sono conformi a REST.
Manipolazione delle risorse tramite rappresentazioni
When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource.
GraphQL può soddisfare questo, a condizione che l'attributo identificativo risorsa sia incluso per ogni richiesta. vale a dire il seguente non sarebbe valido:
{
books {
title
author: {
name
}
}
}
ma il seguente è valido:
{
books {
id
title
author: {
id
name
}
}
}
Anche se direi che una buona API non dovrebbe restituire i dati di cui non abbiamo bisogno. Il cliente dovrebbe scegliere se desidera o meno l'ID, ma sto divagando.
Messaggi auto-descrittivi
Each message includes enough information to describe how to process the message. For example, which parser to invoke can be specified by a media type.
GraphQL soddisfa questo dato in quanto i dati restituiti sono JSON e il tipo di supporto è application/json .
Hypermedia come motore dello stato dell'applicazione (HATEOAS)
Having accessed an initial URI for the REST application—analogous to a human Web user accessing the home page of a website—a REST client should then be able to use server-provided links dynamically to discover all the available actions and resources it needs. As access proceeds, the server responds with text that includes hyperlinks to other actions that are currently available. There is no need for the client to be hard-coded with information regarding the structure or dynamics of the application.
GraphQL non soddisfa perfettamente HATEOAS , ma nemmeno molte altre API reali che dichiarano di essere RESTful.
Questo criterio è anche inutile quando si utilizza GraphQL, perché tutto viene eseguito su un singolo URI.
Tuttavia, vale la pena notare che GraphQL ha anche una funzione chiamata Introspection , che consente al client di ottenere informazioni su cosa interroga il supporto del server e la documentazione, che in un modo è più utile di un semplice URI.
Conclusione
Quindi, per concludere, sembra che GraphQL soddisfi:
- Architettura del server client
- apolidia
- Sistema a strati
- Identificazione delle risorse nelle richieste
- Messaggi auto-descrittivi
Applicando che id è richiesto per ogni risorsa, può anche essere fatto per supportare:
- Cache
- Manipolazione delle risorse tramite rappresentazioni
E non ha davvero bisogno di supporto:
- Hypermedia come motore dello stato dell'applicazione (HATEOAS), perché tutto viene eseguito su un URL e GraphQL ha introspezione.
Quindi possiamo concludere che GraphQL soddisfa REST, ad eccezione di HATEOAS (che IMO è comunque la parte peggiore di REST).
Sono corretto o ho frainteso le specifiche REST