Request Process Flow

The request process flow is roughly based on Alan Dean's status code activity diagram. The methods defined are in the order in which processing occurs. Each step has a method named after the HTTP response check and prefixed with is_ that must return False to pass, e.g. is_not_found. For some methods there are one more properties associated with a given method for toggling specific behaviors.

503 Service Unavailable

Properties

If True, the service will be unavailable indefinitely. If an integer or datetime is used, the Retry-After header will set. An integer can be used to define a seconds delta from the current time (good for unexpected downtimes). If a datetime is set, the number of seconds will be calculated relative to the current time (good for planned downtime).

• unavailable (default: False)

414 Request URI Too Long (not implemented)

This is (and should be) handled upstream by the Web server and thus not implemented here.

400 Bad Request (not implemented)

Many services respond with this code when entities are unprocessable. This should really be a 422 Unprocessable Entity. Most actual bad requests are handled upstream by the Web server when parsing the HTTP message.

401 Unauthorized

Check if the request is authorized to access this resource. Override this function implementation and authorization check.

403 Forbidden

Check if this resource is forbidden for the request. Override this function implementation and authorization check.

501 Not Implemented (not implemented)

This technically refers to a service-wide response for an unimplemented request method, again this is upstream.

429 Too Many Requests

Both rate_limit_count and rate_limit_seconds must not be falsy values to be applicable. Setting these properties will enforce a global rate-limit. The method can be overridden to support more finer grain control (such as based on user or session).

Properties

• rate_limit_count (default: None)
• rate_limit_seconds (default: 3600 (1 hour))

405 Method Not Allowed

The request method is not implemented or allowed by the resource. If this property is not defined explicitly, introspection of the resource will occur and look for valid methods with the same name as the methods defined in the HTTP spec including: get, post, put, delete, patch, trace, head, and options.

Properties

• allowed_methods

406 Not Acceptable

Checks Accept and Accept-* headers to ensure the request is acceptable for processing.

Properties

• supported_accept_types (default: ('application/json',))

Methods

• accept_type_supported
• accept_language_supported
• accept_charset_supported
• accept_encoding_supported

415 Unsupported Media Type

Check if the entity Content-Type supported for decoding. This check occurs only if a request body has been supplied.

Properties

• supported_content_types (defaults to supported_accept_types)

Methods

• content_type_supported
• content_encoding_supported
• content_language_supported

413 Request Entity Too Large

Check if the entity is too large for processing. This check occurs only if a request body has been supplied.

Properties

• max_request_entity_size (default: None)

404 Not Found

Check if this resource exists. Note, if this requires a database lookup or some other expensive lookup, the relevant object may be attached to the request or response object to be used dowstream in the handler. This prevents multiple database hits or filesystem lookups.

410 Gone

Check if this resource used to exist, but does not anymore. A common strategy for this when dealing with this in a database context is to have an archived or deleted flag that can be used associated with the given lookup key while the rest of the content in the row may be deleted.

428 Precondition Required

Properties

Prevents the "lost udpate" problem and requires client to confirm the state of the resource has not changed since the last GET request. This applies to PUT and PATCH requests. If True, PUT and PATCH requests are required to have a conditional header for verifying the operation applies to the current state of the resource on the server. This must be used in conjunction with either the use_etags or use_last_modified option to take effect.

• require_conditional_request (default: False)

412 Precondition Failed

Conditional requests applies to GET, HEAD, PUT, and PATCH. For GET and HEAD, the request checks the either the entity changed since the last time it requested it, If-Modified-Since, or if the entity tag (ETag) has changed, If-None-Match.