Routing
Also a facade to catch any HTTP method:
Additional and custom HTTP methods can be set using the route
function:
With an array
, you can listen for multiple HTTP methods on the same handler:
Route parameters
Route parameters can be defined using Regular Expressions:
Or using a little syntax for creating named groups, that is just wrapping the parameter name around curly-brackets:
The above will match anything, not only numbers. For a fine-grained control, please use Regular Expressions.
Optional parameters
Optional named parameters can be defined using the question mark ?
as sufix:
To avoid the need of a trailing slash, add a question mark after it, like regex (because it is regex):
Route handlers
The <handler>
placeholder you saw is where you can put the route logic and it can be contained on the following:
Callables
As a Closures:
As a method call on array-syntax:
As a static method call string-syntax:
As any kind of callable:
Filenames
Handlers can be a String representing the filename of another PHP file, route parameters will be available at the global $params
variable:
Resources
CRUD routes can be auto-magically be defined for convenience using the Rails and Laravel pattern.
Given this resource declaration:
Siler will look for files at path/to/files
matching the HTTP URI according to the table below:
HTTP Verb | URI | File |
GET |
|
|
GET |
|
|
POST |
|
|
GET |
|
|
GET |
|
|
PUT |
|
|
DELETE |
|
|
The file structure should look like:
Files
You can also let Siler create the routes recursively looking for files at a base path. Then the files names will be used to define the method and the path.
Siler will interpret periods (.) as slashes and also maintain folder structure at HTTP path:
Filename | Method | Path |
| GET |
|
| POST |
|
| GET |
|
| GET |
|
| GET |
|
| GET |
|
| GET |
|
Since {
and }
are valid chars in a filename, route parameters should work as well, but you can define required parameters prefixing with $
and optional parameters using @
:
Filename | Method | Path |
| GET |
|
| GET |
|
| GET |
|
Any method is valid, it is guessed based on the penultimate "token":
Filename | Method | Path |
| OPTIONS |
|
| X-CUSTOM |
|
Note on handlers
When creating routes, be careful about early and lazy evaluations.
The example above is early, which means it will call FooController
constructor for each request even if it's not a request to /foo
.
To make it lazy you can wrap inside a Closure
:
Now FooController
is called only when there is a match for route /foo
.
One downside is that now you have to explicitly manage path parameters, on the other hand is a best practice to do so.
It is a good time to validate parameters, convert plain string parameters to meaningful types on your domain or resolve dependencies.
Request
Body
You can grab the raw request body using:
Parse as URL-encoded data using:
Parse as JSON using:
$_GET and $_POST superglobals
Or get data from a Form and from the Query String using:
Calling them without arguments will tell Siler to return all the values as an array
:
You can also pass a default value if the key isn't present in the GET or POST super-globals:
Headers
Also conveniently get a header as easy as for the body:
e.g. Serving both JSON and Form requests:
Response
Siler also have convenient functions to simplify HTTP responses.
You can output JSON encoded body with proper headers in just one line:
It will already output the given data, you don't need to call echo
or print
so use carefully, it's not a encoder, it's an output-er.
Headers
Same easy as for Request, you can set HTTP response headers with the header
function at Response
namespace:
Last updated