[Incremental Delivery Questions] How is the response protocol determined in different scenarios

Aperta
  • Qualcosa non va?
#167 10 commenti 3 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Documentazione
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
graphql
Ambito
api, documentation

Direzione di ricerca

Inizia con le sezioni attuali della bozza della specifica che riguardano la negoziazione di HTTP Accept, la distribuzione incrementale, i formati delle risposte e le richieste GET. Esamina ogni scenario rispetto ai requisiti dichiarati nella bozza e documenta un’unica risoluzione coerente per la selezione del content-type, i client non supportati, il comportamento di esecuzione e il supporto per GET.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

question

I have a question regarding how the response protocol is determined for a request that could POTENTIALLY result in multiple payloads.

Scenario: client sends header accept: multipart/mixed with non-"Incremental Delivery" operation

Given we have an operation that does not use defer/stream at all:

query { foo }

Should the response then use the application/(graphql+)json response type or the multipart/mixed response type?

Scenario: clients sends accept: multipart/mixed, application/(graphql+)json with non-"Incremental Delivery" operation

Given we have an operation that does not use defer/stream at all:

query { foo }

Should the response then still use the application/(graphql+)json content-type or the multipart/mixed response type?
According to the current spec draft, the server should always please the order of the accept header listed content-types if possible. Would that still apply if the server is capable of serving both content-types (accept: multipart/mixed and application/(graphql+)json)

Scenario: clients sends header accept: application/(graphql+)json with "Incremental Delivery" operation

query {
  foo
  ... on Query @defer {
    bar
  }
}

Quote from current Spec Draft:

According to the HTTP 1.1 Accept specification, when a client does not include at least one supported content type in the Accept HTTP header, the server MAY choose to respond in one of several ways. The server MUST either:

Disregard the Accept header and respond with the default content type of application/graphql+json, specifying this in the Content-Type header; OR
Respond with a 406 Not Acceptable status code

Should the server in this scenario still send back multipart/mixed or raise a 406 HTTP error?

Should the fact that the client sent an operation with a defer or stream directive be a hint to the server that the client MUST be able to parse it? A client not supporting it, would probably not have requested it in the first place?

Should the server be responsible for merging the results and sending them as a single result to the client?

Should the server do the execution with the defer and stream executor functionality being disabled?

Scenario: clients sends the HTTP GET method

Is incremental delivery via GET allowed or intended?

Lingua principale
JavaScript
Stelle
428
Fork
70
Merge medio
11m
PR unite (30g)
4

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di graphql/graphql-over-http

Tutte le issue di graphql/graphql-over-http

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.