Integrate Requests library

[andyceo]

Hi!

Thank you for your great lib!

I would like to propose integration with Requests, another great python library.

Sometimes I have an API given on another language, and all I have to do is to generate Requests objects based on given opeapi.yaml file and check API Responses. I want to use your lib and thats why I can not or does not want use Flask.

Usage scenario is something like this:

    req = requests.Request('GET', 'http://88.198.13.202:9051/info')

    openapi_request = RequestsOpenAPIRequest(req)
    validator = RequestValidator(spec)
    result = validator.validate(openapi_request)

    result.raise_for_errors()
    errors = result.errors
    print('Request errors:', errors)

    r = req.prepare()
    s = requests.Session()
    res = s.send(r)

    openapi_response = RequestsOpenAPIResponse(res)
    validator = ResponseValidator(spec)
    result = validator.validate(openapi_request, openapi_response)

    result.raise_for_errors()
    errors = result.errors
    print('Response errors:', errors)

Repeat the above for all endpoints in paths in openapi.yaml.

[codecov]

Codecov Report

Merging #24 into master will decrease coverage by 1.4%.
The diff coverage is 53.57%.

@@            Coverage Diff             @@
##           master      #24      +/-   ##
==========================================
- Coverage   98.55%   97.14%   -1.41%     
==========================================
  Files          18       18              
  Lines         897      946      +49     
==========================================
+ Hits          884      919      +35     
- Misses         13       27      +14

Impacted Files	Coverage Δ
openapi_core/wrappers.py	85.1% <53.57%> (-13.41%)	⬇️
openapi_core/schemas.py	96.73% <0%> (-0.55%)	⬇️
openapi_core/media_types.py	97.5% <0%> (+1.66%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8d92c25...05a844d. Read the comment docs.

[AMcManigal]

I don't think your implementation for the path_pattern is going to work for routes that have path parameters. The library does a dictionary lookup where it expects the path_pattern to equal the path in the spec. For example, consider the path '/pets/{petId}'. Your implementation will cause the library to try to look up something like '/pets/123' in the paths dict, which will cause the validation to fail because that's not the way the path is defined in the OAS spec.

[AMcManigal]

I'll be pushing a PR sometime today that should deal with the path_pattern problem. If accepted then your implementation will likely work correctly with my addition.

[AMcManigal]

Actually, it's more complicated than I thought. I have something that would work for the path_pattern but it doesn't account for the path and query parameters.

[andyceo]

Yes, if we have route pattern, this would not work. I think we should add route pattern when creating RequestsOpenAPIRequest object:

openapi_request = RequestsOpenAPIRequest(req, url_pattern='/pets/{petId}')

Currently I am working on it, could not say when it would ready...

[AMcManigal]

I'm wondering if this should actually be a part of the library. Consider this.

We already have a regex-like pattern in the route:
/pets/{petId})
If we convert this into a true regex then we should be able to match against every possible pattern that this path can have:
/pets/(.*)
It makes sense to do this in the spec object rather than the request object because the spec contains the patterns of every possible path in the API. Thus we merely match the url against all possible paths, which is O(n) though n should be small, and pick the pattern that matches the raw url.

The problem then (and this is where I am at the moment) is that we must also extract the path path and query parameters. The query params should be able to be parsed easily. The path params require a bit more work since this is part of the validators, but it's definitely doable.

A second option is to pass the spec to the request object and let it figure out everything there. However, I feel it would be far more user friendly to simply be able to have the core library extract this information from a simpler request object since there are plenty or url parsing tools and it would make implementing request wrappers much easier in the future.

[p1c2u]

@andyceo thanks for the contribution. The feature looks very useful. We still need tests though.

[andyceo]

I create a script for testing API of our node.

https://github.com/ergoplatform/ansible/blob/master/files/scripts/check_openapi_responses.py

Curremtly I skip routes with url patterns, found interesting fatal error for /blocks endpoint:

/blocks
Traceback (most recent call last):
  File "./files/scripts/check_openapi_responses.py", line 105, in <module>
    validate(sys.argv[1])
  File "./files/scripts/check_openapi_responses.py", line 83, in validate
    result = validator.validate(openapi_request)
  File "/home/andyceo/.local/lib/python3.5/site-packages/openapi_core/validators.py", line 96, in validate
    raw_value = self._get_raw_value(request, param)
  File "/home/andyceo/.local/lib/python3.5/site-packages/openapi_core/validators.py", line 135, in _get_raw_value
    raw = location[param.name]
TypeError: list indices must be integers or slices, not str

Discovering what is wrong.

I am testing this API: https://github.com/ergoplatform/ergo/blob/master/src/main/resources/api/openapi.yaml

[andyceo]

Make commit with bugfix for message above. Update Pull Request description.

[andyceo]

Complete RequestsOpenAPIRequest object properties body and mimetype.

Change PR head message respectively.

[p1c2u]

Closing in favor of #209