HTTP status code handling with Kiota API clients
Kiota uses the specified HTTP status codes in OpenAPI descriptions to determine return types. It also attempts to handle cases where APIs return a status code other than the one specified in the OpenAPI description.
During API client generation, Kiota follows these rules to map status codes described by the OpenAPI description. The following table is ordered, which means the first rule that matches is used during generation.
Code | Schema is present | Result type |
---|---|---|
200-203 | yes | model class |
2XX | yes | model class |
204, 205 | N/A | void |
201, 202 | no | void |
200, 203, 206 | no | stream |
2XX | no | stream |
Note
For a schema to be considered present, it must be part of a structured content response (application/json
, application/xml
, text/plain
, text/xml
, text/yaml
).
At runtime, the client can encounter response status codes that differ from what was originally documented due to how HTTP works. Default request adapter implementations follow these rules:
Expected return type | Response status code | Response body is present | Returned value |
---|---|---|---|
model class | 200-203 | yes | deserialized value |
model class | 200-202, 204, 205 | no | null |
void | 200-205 | N/A | void |
stream | 200-203, 206 | yes | stream |
stream | 200-205 | no | null |