vapor-ware / fastapi-rfc7807 Goto Github PK

This allows consumers to use the model where needed. An example would be providing it in route metadata so the OpenAPI docs can render with the schema for a Problem response.

e.g. if we have a subclass of error which we want to include a response header when it is raised and an error returned, we should be able to do so by defining it on the error class subtype.

class Custom(Problem):

    headers = {
        'some-header': 'foobar'
    }

we may want to also have a way to set more dynamic headers, but I think that is a separate future issue.

Can you set python_requires='>=3.6' ?
My project based Centos7 and python 3.6

When running the following example code:

from fastapi import FastAPI
from fastapi_rfc7807 import middleware
import uvicorn

app = FastAPI()
middleware.register(app)

@app.get('/error')
async def error():
    raise ValueError('something went wrong')


def main():
    uvicorn.run(
        "coordinates_transformation_api.main:app", workers=2, port=8080, host="0.0.0.0"
    )

if __name__ == "__main__":
    main()

With the following versions and Python v3.11.4:

fastapi==0.100.1
fastapi-rfc7807==0.5.0
uvicorn==0.23.2

With:

python main.py

The application fails with the following message:

ImportError: cannot import name 'get_model_definitions' from 'fastapi.openapi.utils' (/home/anton/.local/lib/python3.11/site-packages/fastapi/openapi/utils.py)

Error is caused by FastAPI that recently switched to Pydantic v2. See the commit here.

I created this issue mainly to document the issue, and to perhaps revisit later myself (considering the lack of activity in the project).

Should set up a readthedocs page going over installation, usage, and different examples. This is covered at a high level in the README but should be expanded upon further.

Not an Issue but are there examples of how to use fastapi-rfc7807 in a try-except block?

just need the latest pipeline version I believe.

Hi @edaniszewski ,
first of all thanks for providing that package to the community. I just reviewed your package because we think about using it in our software development operation: this is very well made.

But with looking into RFC 7807 and checking on the problem details object members at some points your implementation does not seem to be compliant:

1. exc_type
   Here you add an additional object member exc_type to the problem object. This member type is not present in the RFC documentation. So I would consider this beeing out of specs.
   Also I am asking myself why a additional object property is needed here. When I read the specs I think that exception name could be just added to the title property of the problem object:

"title" (string) - A short, human-readable summary of the problem
type. It SHOULD NOT change from occurrence to occurrence of the
problem, except for purposes of localization (e.g., using
proactive content negotiation; see [RFC7231], Section 3.4).

2. errors
   The errors object member also do not exist in the RFC 7807 specification. Looking at the detail object property and your implementation. I am asking myself why the errors aren't just rendered as a string and concatenated to the detail string as this should be "specific to the occurence of the problem":

"detail" (string) - A human-readable explanation specific to this
occurrence of the problem.

Maybe you can let me know your thinking behind these implementations. Especially not so sure what your thinking was with regard to that specific parts of the RFC 7807 I quoted above. There might have been good reasons to do it like this, but I don't know.

Regards, Max

Using the custom subclass example at https://github.com/vapor-ware/fastapi-rfc7807/blob/master/examples/basic.py, I have a similar construct below. However, I don't understand why it returns a str and not json. The fastapi-rfc7807 code processing the custom subclass is at

My code is:

from fastapi_rfc7807.middleware import Problem

class TableNotFoundError(Problem):
    """ """
    headers = {
        'WWW-Authenticate': 'Bearer',
    }

    def __init__(self, msg: str) -> None:
        super(TableNotFoundError, self).__init__(
            status=500,
            detail=msg,
        )

try:
    do_something(name)
except:
    raise TableNotFoundError("Unknown table: %r" % name)

The response is:

TableNotFoundError: Problem:<{'type': 'about:blank', 'title': 'Internal Server Error', 'status': 500, 'detail': "Unknown table: 'hippo'"}>

This is useful because you may want to specify the response info using the actual content header, e.g. application/problem+json. If you pass the Problem schema to a route's responses as a model, it seems to just use its return type as application/json. Still technically correct, but it could be nice to know the full thing.

Specifying the response would at this point still be left to the user

@app.get(
  path='/',
  responses={
    401: {
        'description': 'something bad',
        'content': {'application/problem+json': {
            'schema': {
                '$ref': '#/components/schemas/Problem',
            },
        }},
    }
  },
)

in the future we could maybe include a util to include some of this boilerplate as well, but that seems out of scope for this issue.

there should be a flag for this in the register method which could be either a string, or bool, defaulting to False.

If True, it will augment the OpenAPI scheme with the Problem schema under the "Problem" name. If a string, it will register it under that string as the name.

If false, it will not register.