Rework and trim down functionality for v3 (discussion)

[sondrelg]

I want to open this ticket to flag some ideas and suggestions for deprecations going forward.

Renaming the package & deprecating logic

Once #116 is resolved, I think it might be a good time to clearly define the purpose of this package, and (perhaps to) get rid of some code.

Unless anyone chimes in with good reasons not to, I would like to:

1. Deprecate the middleware and custom views that were introduced this summer but that I don't even use myself (so I cannot be sure it really works all that well)
2. Deprecate the input validation code
3. Rename the package from django-swagger-tester to django-openapi-response-tester or something similar

I'm assuming almost no one has used the code I'm proposing to deprecate, and if someone wanted an APIView with builtin response validation, this is something anyone could easily do, without it having to live in this repo.

The re-defined purpose of the package could then be to only provide a mechanism for validating API responses against OpenAPI schema response sections. That's basically what we do now, but I think re-branding the package would make the documentation a lot clearer.

Leveraging third party packages

I think @Goldziher's suggestion to add third-party library for schema parsing is a good one, and I don't necessarily think we should stop at one.

Another area of the package that I think could be improved by external dependencies is the whole validation logic. Right now the validation logic is a thick mix of validation logic, parsing logic, and custom exception messages. If we instead were able to reduce the OpenAPI response schema to a plain type-definition, we should be able to completely separate the validation logic from any type of parsing logic, making it everything more concise and predictable. We might even be able to outsource the validation completely, and instead focus on outputting legible error messages.

---

The goal of this would be to remove complexity and to create a clearer purpose for the package. The ideal outcome (in my opinion) is to nail (just) response validation and then stop adding features 🚀

[Goldziher]

Yes, I agree with all of your points. I would suggest making the response validation logic as straightforward as possible and output an informative diff in case of a failure (expected vis-a-vis the received). Staying within the paradigm of django testing / pytest.

[JonasKs]

Finally got some time to have a look. Yes, I agree!😊 Happy New Years!🍾