[−][src]Struct tide::Router
A core type for routing.
The Router
type can be used to set up routes and resources, and to apply middleware.
Methods
impl<Data: Clone + Send + Sync + 'static> Router<Data>
[src]
pub fn at<'a>(&'a mut self, path: &'a str) -> Resource<'a, Data>
[src]
Add a new resource at the given path
, relative to this router.
Routing means mapping an HTTP request to an endpoint. Here Tide applies a "table of contents" approach, which makes it easy to see the overall app structure. Endpoints are selected solely by the path and HTTP method of a request: the path determines the resource and the HTTP verb the respective endpoint of the selected resource. Example:
app.at("/").get(async || "Hello, world!");
A path is comprised of zero or many segments, i.e. non-empty strings separated by '/'. There
are two kinds of segments: concrete and wildcard. A concrete segment is used to exactly
match the respective part of the path of the incoming request. A wildcard segment on the
other hand extracts and parses the respective part of the path of the incoming request to
pass it along to the endpoint as an argument. A wildcard segment is either defined by "{}"
or by "{name}" for a so called named wildcard segment which can be extracted using
NamedSegment
. It is not possible to define wildcard segments with different names for
otherwise identical paths.
Wildcard definitions can be followed by an optional wildcard modifier. Currently, there is
only one modifier: *
, which means that the wildcard will match to the end of given path,
no matter how many segments are left, even nothing. If there is a modifier for unnamed
wildcard definition, {}
may be omitted. That is, {}*
can be written as *
. It is an
error to define two wildcard segments with different wildcard modifiers, or to write other
path segment after a segment with wildcard modifier.
Here are some examples omitting the HTTP verb based endpoint selection:
app.at("/"); app.at("/hello"); app.at("/message/{}"); app.at("add_two/{num}"); app.at("static/{path}*"); app.at("single_page_app/*");
Notice that there is no fallback route matching, i.e. either a resource is a full match or not, which means that the order of adding resources has no effect.
pub fn middleware(
&mut self,
middleware: impl Middleware<Data> + 'static
) -> &mut Self
[src]
&mut self,
middleware: impl Middleware<Data> + 'static
) -> &mut Self
Apply middleware
to this router.
Note that the order of nesting subrouters and applying middleware matters. If there are nested subrouters before the method call, the given middleware will be applied after the subrouter middleware.
router.at("a1").nest(|router| { router.middleware(a); router.at("").get(async || "A then B"); }); router.middleware(b); router.at("a2").nest(|router| { router.middleware(a); router.at("").get(async || "B then A"); });
pub fn config<T: Any + Debug + Clone + Send + Sync>(
&mut self,
item: T
) -> &mut Self
[src]
&mut self,
item: T
) -> &mut Self
Add a default configuration item
for this router.
The default configuration will be applied when the router setup ends.
Auto Trait Implementations
Blanket Implementations
impl<T> From for T
[src]
impl<T, U> Into for T where
U: From<T>,
[src]
U: From<T>,
impl<T, U> TryFrom for T where
U: Into<T>,
[src]
U: Into<T>,
type Error = !
try_from
)The type returned in the event of a conversion error.
fn try_from(value: U) -> Result<T, <T as TryFrom<U>>::Error>
[src]
impl<T> Borrow for T where
T: ?Sized,
[src]
T: ?Sized,
impl<T> Any for T where
T: 'static + ?Sized,
[src]
T: 'static + ?Sized,
impl<T> BorrowMut for T where
T: ?Sized,
[src]
T: ?Sized,
fn borrow_mut(&mut self) -> &mut T
[src]
impl<T, U> TryInto for T where
U: TryFrom<T>,
[src]
U: TryFrom<T>,