Skip to content

Commit 7567683

Browse files
authored
Add notes from April WG (#351)
1 parent 47cf138 commit 7567683

File tree

2 files changed

+67
-1
lines changed

2 files changed

+67
-1
lines changed

.prettierignore

Lines changed: 6 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,9 @@
11
# PRs to Working Group documents should be minimal effort - no need to force formatting compliance
2-
/working-group/
2+
/working-group/*.md
3+
/working-group/agendas
4+
/working-group/notes/2022
5+
/working-group/notes/2023
6+
/working-group/notes/2024
7+
/working-group/notes/*/summary-*
38
# To maintain the expressiveness of the original poster, we do not auto-format RFCs
49
/rfcs/

working-group/notes/2025/2025-04.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
1+
# GraphQL-over-HTTP WG - April 2025
2+
3+
**Watch the replay**:
4+
https://www.youtube.com/watch?v=nHSixplvCc0&list=PLP1igyLx8foEz9127xc0SsabIrbTMt9g5
5+
6+
Agenda:
7+
https://github.com/graphql/graphql-over-http/blob/main/working-group/agendas/2025/04-Apr/24-graphql-over-http-wg-april-2025.md
8+
9+
Participants:
10+
11+
- @shane32
12+
- @martinbonnin
13+
- @benjie
14+
15+
## Watershed
16+
17+
- The watershed was January, 2025. It is now April, should we remove it?
18+
- Benjie asked for some actual data. GraphQL mostly uses 200.
19+
- If we were to keep the watershed, it should be well in the future.
20+
- Aim: Merge next Thursday, based on preexisting PR approvals by shane32,
21+
enisdenjo, martinbonnin, benjie.
22+
23+
## Partial success response code
24+
25+
- 200 for everything is a common complaint
26+
- With our new status code, we allow non 2xx for errors.
27+
- It would be good to have a non-200 status code for partial responses.
28+
- There is no suitable HTTP status code for now.
29+
- WebDav has 207 (multi-status).
30+
- 206 is about byte ranges. We don’t want to overload this.
31+
- We should allocate ours in the high 29x (294? 247?)
32+
- Shane: this would be useful for logging, what else?
33+
- Status codes are not really useful for the clients. They can deduce everything
34+
from the body.
35+
- It’s for proxies, status monitoring, etc…
36+
- Is it a MUST? Is it a SHOULD?
37+
- Shane: how do we make sure we are not conflicting?
38+
- It would be good to have unified status code for future tooling.
39+
- Benjie: We are not supposed to allocate our own status codes. But some people
40+
have done it (Twitter, 420)
41+
- It’s for your own backend tooling => If you choose to not do it, this is fine.
42+
- Martin: why do we even mandate 2xx?
43+
- Benjie: It’s a tradition, better for client compatibility .
44+
- We also want to reuse 4xx and 5xx
45+
- Ideally we want everyone to implement it in the same way.
46+
- Shane: Helps improve logging.
47+
- Not sure I would mandate it because it’s not on IANA’s list but that’s the
48+
only real reason.
49+
- In all cases, having a specific code would be really useful.
50+
51+
## Security
52+
53+
- Merge the security note?
54+
55+
## Triaging
56+
57+
- If everyone wants to do some triage, let’s go for it.
58+
59+
## Release
60+
61+
- Aim to release together with the new spec release in July?

0 commit comments

Comments
 (0)