Allow using wildcard in request URI #36
Comments
|
Hi, This is the dup of #34. Please read my answer there. As it came up from two different people, I think I'll add some basic support for this - however I still do not want to add any routing implementation as it would be a reimplementation of Flask. It means that the handlers will be looked up in a sequential order (in the same order as there were defined) with no respect of how narrow is the match. What I mean by "basic" is the following:
The library itself would have no implementation of the URIPattern class, it would be up to the developer to implement something (eg prefix/suffix matches, glob matching, etc). |
|
Thanks for you answer! Just read your answer in #34 and it's great that we are able to do this 👍. But it might indeed be good to also implement a way to also accept regex as that seems a bit more user-friendly. If you need any help I'll be happy to assist implementing it 👌 |
Extend URI matching functionality which now accepts: * a URIPattern object, whose match() method will be called * a compiled regexp returned by re.compile(). In this case the URI will be matched against the regexp. In both cases the URI will be an absolute path starting with a slash. Fixes #34 and #36.
Extend URI matching functionality which now accepts: * a URIPattern object, whose match() method will be called * a compiled regexp returned by re.compile(). In this case the URI will be matched against the regexp. In both cases the URI will be an absolute path starting with a slash. Fixes #34 and #36.
|
cc: @arturpat I've submitted the PR #37 to implement pattern matching. Could you please have a look at it? The key points are:
I also kept the possibility to specify any object whose |
Extend URI matching functionality which now accepts: * a URIPattern object, whose match() method will be called * a compiled regexp returned by re.compile(). In this case the URI will be matched against the regexp. In both cases the URI will be an absolute path starting with a slash. Fixes #34 and #36.
Extend URI matching functionality which now accepts: * a URIPattern object, whose match() method will be called * a compiled regexp returned by re.compile(). In this case the URI will be matched against the regexp. In both cases the URI will be an absolute path starting with a slash. Fixes #34 and #36.
Extend URI matching functionality which now accepts: * a URIPattern object, whose match() method will be called * a compiled regexp returned by re.compile(). In this case the URI will be matched against the regexp. In both cases the URI will be an absolute path starting with a slash. Fixes #34 and #36.
|
I've merged the PR request, thanks for your comments! |
|
I've released 0.3.5. Thanks for using this library! |
|
Hey, Thanks for developing this great library, |
Currently when using the
httpserver.expect_requestfunction, I am only allowed to use the full URI string. It would be nice if it would also accept URI's with wildcards or regex.For instance, I have an endpoint called
GET /users/{USER_ID}/rolethat will return the role of a user with a given USER_ID. If I would like to mock this endpoint I would have to specify ahttpserver.expect_requestfor each of the users I am using in my tests:httpserver.expect_request("/users/1/role").respond_with_json("admin")httpserver.expect_request("/users/2/role").respond_with_json("admin")httpserver.expect_request("/users/3/role").respond_with_json("admin")It would be way more convenient if we could just pass in a wildcard instead:
httpserver.expect_request("/users/*/role").respond_with_json("admin")The text was updated successfully, but these errors were encountered: