Routing
The Handler type
A Handler, as the name implies, handle requests.
A Handler responds to an HTTP request. It writes reply headers and data to the Context.ResponseWriter() and then return. Returning signals that the request is finished; it is not valid to use the Context after or concurrently with the completion of the Handler call.
Depending on the HTTP client software, HTTP protocol version, and any intermediaries between the client and the iris server, it may not be possible to read from the Context.Request().Body after writing to the context.ResponseWriter(). Cautious handlers should read the Context.Request().Body first, and then reply.
Except for reading the body, handlers should not modify the provided Context.
If Handler panics, the server (the caller of Handler) assumes that the effect of the panic was isolated to the active request. It recovers the panic, logs a stack trace to the server error log and hangs up the connection.
Once the handler is registered, we can use the returned Route
instance to give a name to the handler registration for easier debugging or match relative paths in views. For more information, checkout the Reverse lookups section.
Behavior
Iris' default behavior is to accept and register routes with paths like /api/user
, without a trailing slash. If a client tries to reach $your_host/api/user/
then the Iris router will automatically permant redirect this to $your_host/api/user
in order to be handled by the registered route. This is the modern way to design APIs.
However, if you want to disable path correction for the requested resources you can pass the iris.WithoutPathCorrection
option of the iris Configuration to your app.Run
. Example:
If you want to keep the same handler and route for /api/user
and /api/user/
paths without redirection(common scenario) use just the iris.WithoutPathCorrectionRedirection
option instead:
API
All HTTP methods are supported, developers can also register handlers on the same path with different methods.
The first parameter is the HTTP Method, second parameter is the request path of the route, third variadic parameter should contain one or more iris.Handler
executed by the registered order when a client requests for that specific resouce path from the server.
Example code:
In order to make things easier for the end-developer, iris provides method helpers for all HTTP Methods. The first parameter is the request path of the route, second variadic parameter should contains one or more iris.Handler executed by the registered order when a user requests for that specific resouce path from the server.
Example code:
Offline Routes
There is one special method in Iris that you can use too. It's called None
and you can use it to hide a route from outsiders but still able to call it from other route's handlers through the Context.Exec
method. Each API Handle method returns the Route value back. A Route the IsOnline
method which reports back the current state of that route. You can change the state of the route from offline to online and visa-versa through its Route.Method
field's value. Of course each change of the router at serve-time requires an app.RefreshRouter()
call which is safe to use. Take a look below a more complete example:
How to run
go run main.go
Open a browser at
http://localhost:8080/invisible/iris
and you'll see that you get a404 not found
error,however the
http://localhost:8080/execute
will be able to execute that route.Now, if you navigate to the
http://localhost:8080/change
and refresh the/invisible/iris
tab you'll see that you can see it.
Grouping Routes
A set of routes that are being groupped by path prefix can (optionally) share the same middleware handlers and template layout. A group can have a nested group too.
.Party
is being used to group routes, developers can declare an unlimited number of (nested) groups.
Example code:
The same could be also written using the PartyFunc
method which accepts the child router(the Party).
Path Parameters
Unlike other routers you'd seen, the Iris' one can handle various route paths without confliction between them.
Matches only GET "/".
Matches all GET requests prefixed with "/assets/**/*"
, it's a wildcard with ctx.Params().Get("asset")
equals to any following path after the /assets/
.
Matches all GET requests prefixed with "/profile/"
and followed by a single path part.
Matches only GET "/profile/me"
and it does not conflict with /profile/{username:string}
or any root wildcard /{root:path}
.
Matches all GET requests prefixed with /users/
and followed by a number which should be equal or higher than 1.
Matches all DELETE requests prefixed with /users/
and following by a number which should be equal or higher than 1.
Matches all GET requests except the ones that are already handled by other routes. For example in this case by the above routes; /
, /assets/{asset:path}
, /profile/{username}
, "/profile/me"
, /user/{userid:int ...}
. It does not conflict with the rest of the routes(!).
Matches all GET requests of:
/u/abcd maps to :alphabetical (if :alphabetical registered otherwise :string)
/u/42 maps to :uint (if :uint registered otherwise :int)
/u/-1 maps to :int (if :int registered otherwise :string)
/u/abcd123 maps to :string
Matches all GET requests of /abctenchars.xml
and /abcdtenchars
respectfully.
You may wonder what the {id:uint64}
or :path
or min(1)
are. They are (typed) dynamic path parameters and functions can be registered on them. Learn more by reading the Path Parameter Types.
Last updated