Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

API router does not respect WAGTAIL_APPEND_SLASH setting

See original GitHub issue

Issue Summary

The API router will append slashes whether the WAGTAIL_APPEND_SLASH is set to True or False. The behaviour is hardcoded in wagtail.api.v2.router.py.

Changing the behaviour in the router might qualify as a breaking change, if the slash is just removed in case WAGTAIL_APPEND_SLASH is set to False. Right now clients are redirected from endpoint_without_slash to endpoint_with_slash with WAGTAIL_APPEND_SLASH, but that won’t happen automatically the other way around.

DRF has the trailing_slash argument for its router implementations so this might be a compromise to make the behaviour configurable while maintaining backwards compatibility until a breaking change is possible in the next (major?) version.

I’ll gladly submit a PR for a fix once we settled for a solution.

Thank you for your time!

Steps to Reproduce

Follow the instructions in the documentation to setup the API
Set WAGTAIL_APPEND_SLASH to False in settings
Start the dev server
Goto /api/v2/pages (which is immediately redirected to /api/v2/pages/.

I have confirmed that this issue can be reproduced as described on a fresh Wagtail project: yes

Technical details

Python version: 3.8.2
Django version: 3.0.5
Wagtail version: 2.8.1
Browser version: Chromium 81

Issue Analytics

State:
Created 3 years ago
Reactions:3
Comments:7 (2 by maintainers)

Top GitHub Comments

1reaction

kaedrohocommented, Feb 7, 2022

Thanks @kmohrf and @shipskin!

Unless there is a good reason for it, I’m against us making this change.

I don’t think this is a bug, WAGTAIL_APPEND_SLASH is only supposed to apply to page URLs by design. We support this because these URLs are what appear in a users browser and may be hand typed and this is not the case for the API.

Supporting this would have a couple of disadvantages:

It doubles the amount of URLs we might have to cache and invalidate from a cache
It makes Wagtail implementations slightly different from one another making it more difficult to write a single client library that works across many Wagtail sites

0reactions

gasmancommented, Feb 7, 2022

This was separately proposed and rejected in #7421 - sorry for not catching this earlier.

Top Results From Across the Web

Routers - Django REST framework

Resource routing allows you to quickly declare all of the common routes for a given resourceful controller. Instead of declaring separate routes for...

Router basename is not able to match the URL because it ...

It's like the v6 doesn't respect URL fragments at all. I need the URL fragments so that when a user refreshes a page...

Working with routes for HTTP APIs - Amazon API Gateway

Learn about developing HTTP API routes. ... You can create a $default route that acts as a catch-all for requests that don't match...

API Reference - Express 4.x

You can use this mechanism to impose pre-conditions on a route, then pass control to subsequent routes if there is no reason to...

Rails Routing from the Outside In - Ruby on Rails Guides

How to interpret the code in config/routes.rb . How to construct your own routes, ... Note that the id does not need to...