-
-
Notifications
You must be signed in to change notification settings - Fork 6.9k
Schemas should automatically respect API root location #4401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm not sure that we can automagically determine this in a nice way. Setting the path explicitly is the right thing for you to do, at least for now. Perhaps we'll revisit this at some point in the future. |
I would like to bring this up again, as the bug is not fixed. The issue actually is that the URLs in the schema are wrong. Why is it not possible to simply use |
@klada - Be specific. There's a whole bunch of fixes in the incoming 3-5 branch. If you believe there's still an issue on that branch then show me an example case that we can use to help resolve things. |
Okay, have read through this issue again. Going to re-iterate this:
Yes, that means making sure you know where it's located. Them's the breaks. I'll take another review of this prior to the 3.5 release, but I doubt that aspect is going to change. |
@tomchristie, to @klada's point, this does violate DRY. I think I gave a pretty detailed example case in the description, if there's something else you'd like to see, I'm happy to put something together. As far as this not changing, is there something specific blocking this? I dug through the schema URL setup code, only issue I found was that I wasn't able to inspect the |
Okay, on review can confirm that this issue is resolved in the upcoming 3.5 release. And you're right, the example was plenty specific enough. There's a few further improvements that I can see are also required based on the example here, which I'll work towards resolving prior to the release. |
Reopening to leave as a placeholder for resolving schema layout with URL prefixes. |
Resolved via 69b4acd (incoming in 3.5) Thanks for having highlighted this & apologies for not having fully understood the issue on first pass! |
* Start test case * Added 'requests' test client * Address typos * Graceful fallback if requests is not installed. * Add cookie support * Tests for auth and CSRF * Py3 compat * py3 compat * py3 compat * Add get_requests_client * Added SchemaGenerator.should_include_link * add settings for html cutoff on related fields * Router doesn't work if prefix is blank, though project urls.py handles prefix * Fix Django 1.10 to-many deprecation * Add django.core.urlresolvers compatibility * Update django-filter & django-guardian * Check for empty router prefix; adjust URL accordingly It's easiest to fix this issue after we have made the regex. To try to fix it before would require doing something different for List vs Detail, which means we'd have to know which type of url we're constructing before acting accordingly. * Fix misc django deprecations * Use TOC extension instead of header * Fix deprecations for py3k * Add py3k compatibility to is_simple_callable * Add is_simple_callable tests * Drop python 3.2 support (EOL, Dropped by Django) * schema_renderers= should *set* the renderers, not append to them. * API client (#4424) * Fix release notes * Add note about 'User account is disabled.' vs 'Unable to log in' * Clean up schema generation (#4527) * Handle multiple methods on custom action (#4529) * RequestsClient, CoreAPIClient * exclude_from_schema * Added 'get_schema_view()' shortcut * Added schema descriptions * Better descriptions for schemas * Add type annotation to schema generation * Coerce schema 'pk' in path to actual field name * Deprecations move into assertion errors * Use get_schema_view in tests * Updte CoreJSON media type * Handle schema structure correctly when path prefixs exist. Closes #4401 * Add PendingDeprecation to Router schema generation. * Added SCHEMA_COERCE_PATH_PK and SCHEMA_COERCE_METHOD_NAMES * Renamed and documented 'get_schema_fields' interface.
This issue is still present in 3.5. Please see this demo project for a quick demonstration of the issue. I have also included a README containing the current (wrong) and the expected corejson output. |
As far as I'm concerned it's still present in the latest release. It's especially annoying when coreapi client is being used, because there's no way to add a prefix manually on the client side. Is this considered not an issue anymore? Any hints for non-hacky solutions? |
So there's a test added for this 69b4acd#diff-42ea969a60c167b848d4c4910d590060R294 I'd very happily look at a PR that included/added a failing example showing what the issue is meant to be. |
Thanks for pointing out! I guess the test case I'm looking for is settings.BASE_URL = '/some/prefix/', which the test doesn't cover. |
@moorchegue Does the |
Oh, yes, it does. Thanks a lot! |
Creating a schema should automatically provide any path prefixes to the registered router urls instead of defaulting to /.
It's possible to manually set this prefix using the DefaultRouter schema_url paramter, but this requires knowing where the router will be wired into Django URLs.
Steps to reproduce
Install django, rest framework, and coreapi. Configure normal Django boilerplate
Create a viewset
Create a router with the
schema_title
argument to setup automatic CoreAPI renderer and register viewsets.Include router URLs under a path not at root /
Get schema document and verify url does not include API path prefix
Expected behavior
Using coreapi cli, use any actions following schema tutorial in docs (http://www.django-rest-framework.org/tutorial/7-schemas-and-client-libraries/)
Get schema document
Run list action
Actual behavior
Get schema document
Run list action
The text was updated successfully, but these errors were encountered: