|
| 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