Optional final slash in admin endpoints about docs.konghq.com HOT 14 CLOSED

EVERY command? seems excessive, should only be for internal API calls that need it.

from docs.konghq.com.

Just for the trailing slash? I would rather add a trailing slash...

from docs.konghq.com.

agreed with @thibaultcha

from docs.konghq.com.

This has been fixed in a separate branch that will be merged into master

from docs.konghq.com.

What was fixed? How? What was the problem?

from docs.konghq.com.

The trailing slash problem, by simply duplicating the endpoints since Lapis doesn't support regex-matching in routes.

from docs.konghq.com.

This might seem like a solution but since every other plugin will force people to use tralling slash, I think it is going to create inconsistencies. I would rather have a trailing slash always mandatory, than having it optional on some endpoints (where the endpoint is duplicated) and not there on other endpoints (when the developer did not implement a duplicated endpoint)

from docs.konghq.com.

I wanted to do that too, but @nijikokun @SGrondin and @montanaflynn really liked having supports for routes with and without a final slash, and without any redirect, so that's why I introduced it. The only thing is that we are duplicating routes, and as you said it could lead to inconsistencies in the future, although inconsistencies could be fixed by not allowing plugins to create routes using the Lapis app object, but an intermediate function, like:

add_get_route("/hello/world", function(self)
  -- Do something
end)

and add_get_route basically just replicates the embedded function in:

function add_get_route(route, cb)
  app.get(route, cb)
  app.get(route.."/", cb)
end

This could be an option that will mitigate the inconsistencies until Lapis introduces better support for optional slashes.

from docs.konghq.com.

..., and without any redirect, ...

I only said that POST /apis should work. A 301 redirect would be fine with me.

from docs.konghq.com.

Redirects are not automatically followed by curl, so for example if making a request to POST /apis/ returns a 301 redirect to /apis, curl will not automatically follow it and nothing will happen unless the -L parameter is provided, so that's why this issue was originally labeled as: "Using -L in every curl command".

To just make every request work without additional curl arguments on, for example, both /apis/ and /apis, the systems needs to explicitly define both routes.

The redirect is the most technically correct solution and I was okay with that, the only problem is that I do agree we @SGrondin that adding a -L argument to curl commands might not be obvious and add extra complexity.

So here the choice is between making something technically more correct, but could create headaches to our users, or less technically correct (both from a code and an HTTP interface perspective) but easier to use. I wanted the first one, but then I changed my mind when I a few days ago I tried to make a request that didn't return any body in the result, and confused me for 10 minutes. Appending -i then finally showed why: it was a 301 redirect response which by default has no body.

I believe that in the end @SGrondin and @nijikokun are correct, and the focus should be to avoid creating pain to our users. Both curl -d ".." /apis/and curl -d ".." /apis should just work out of the box without any additional curl argument. Thoughts?

from docs.konghq.com.

Thanks for clearing that up for me, I didn't know the reasoning behind adding curl's -L "Follow Redirects" flag and missed all the discussion between you @SGrondin and @nijikokun.

On one hand I would prefer them to both "just work" but on the other I think adding a body with the error "missing trailing slash" is enough to avoid any confusion, especially if the solution's implementation adds technical debt and inconsistencies as @thibaultcha described.

from docs.konghq.com.

https://github.com/leafo/lapis/blob/master/lapis/application.lua#L339

Lapis supports a default_route on the router which would allow you to make them "just work" rather than a redirect.

A redirect is fine, I don't think that makes curl commands require a -L

from docs.konghq.com.

The default_route is what I was adopting which triggers the redirect. Curl doesn't follow redirects by default unless the -L argument has been set.

A redirect it's just a regular HTTP response with a 301 status code and a Location header telling the client where the new location is. Curl doesn't do any magic unless told so.

from docs.konghq.com.

This has been closed by implementing leafo/lapis#276 which basically allows us to have the same behavior without redirects and -L arguments on curl. The redirect is handled internally.

from docs.konghq.com.