Great framing. GraphQL is a good example of exactly this: with the usual application/json responses, many servers answer 200 even when the query failed, and the real result is an "errors" array next to (or instead of) "data". Partial success is allowed too, so one response can carry some fields and an error for others. A habit that helps: assert that "errors" is absent, or exactly what you expected, before you look at the data. Will a later part of the series cover GraphQL or JSON-RPC, where the status code says even less?
Thanks, and that's a great example. GraphQL does come up in Part 3, where I want to look at why rules enforced on REST also have to hold on other entry points. A refused GraphQL request answering 200 is exactly the kind of trap I want to cover there. Have you found a good way to assert on partial success? I'm curious whether you check the exact errors content or only that the failed fields are the ones you expected
RequestFox
Free API tester and network monitor for Chrome and Firefox.
Great framing. GraphQL is a good example of exactly this: with the usual application/json responses, many servers answer 200 even when the query failed, and the real result is an "errors" array next to (or instead of) "data". Partial success is allowed too, so one response can carry some fields and an error for others. A habit that helps: assert that "errors" is absent, or exactly what you expected, before you look at the data. Will a later part of the series cover GraphQL or JSON-RPC, where the status code says even less?