Documentation edits
This commit is contained in:
parent
e676a17cac
commit
e558d613ab
|
|
@ -3,12 +3,12 @@ Getting Started
|
|||
|
||||
This page provides a brief introduction to WellRESTed. We'll take a tour of some of the features of WellRESTed without getting into too much depth.
|
||||
|
||||
To start, we'll make a "`Hello, world!`_" to demonstrate the concepts of handlers and routing and show how to read variables from the request path.
|
||||
To start, we'll make a "Hello, world!" to demonstrate the concepts of handlers and routing and show how to read variables from the request path.
|
||||
|
||||
Hello, World!
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
Let's start with a very basic "Hello, world!". Here, we will create a server. A ``WellRESTed\Server`` reads the incoming request from the client, dispatches a handler, and transmits a response back to the client.
|
||||
Let's start with a very basic "Hello, world!" Here, we will create a server. A ``WellRESTed\Server`` reads the incoming request from the client, dispatches a handler, and transmits a response back to the client.
|
||||
|
||||
Our handler will create and return a response with the status code set to ``200`` and the body set to "Hello, world!".
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ Routing by Path
|
|||
|
||||
This is a good start, but it provides the same response to every request. Let's provide this response only when a client sends a request to ``/hello``.
|
||||
|
||||
For this, we need a router_. A router_ examines the request and sends the request through to the handler that mataches the request's HTTP method and path.
|
||||
For this, we need a router_. A router_ examines the request and sends the request through to the handler that matches the request's HTTP method and path.
|
||||
|
||||
.. _`Example 2`:
|
||||
.. rubric:: Example 2: Routed "Hello, world!"
|
||||
|
|
@ -119,9 +119,9 @@ Routes can be static (like the one above that matches only ``/hello``), or they
|
|||
Middleware
|
||||
^^^^^^^^^^
|
||||
|
||||
In addition to handlers, which provide responses directly, WellRESTed also supports middlware to act on the requests and then pass them on for other middleware or handlers to work with.
|
||||
In addition to handlers, which provide responses directly, WellRESTed also supports middleware to act on the requests and then pass them on for other middleware or handlers to work with.
|
||||
|
||||
Middleware allows you to compose your application in multiple pieces. In the example, we'll use middleware to add a header to every responce, regardless of which handler is called.
|
||||
Middleware allows you to compose your application in multiple pieces. In the example, we'll use middleware to add a header to every response, regardless of which handler is called.
|
||||
|
||||
.. code-block:: php
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ Defining Handlers and Middleware
|
|||
PSR-15 Interfaces
|
||||
-----------------
|
||||
|
||||
The prefered method is to use the interfaces standardized by PSR-15_. This standard includes two interfaces, ``Psr\Http\Server\RequestHandlerInterface`` and ``Psr\Http\Server\MiddlewareInterface``.
|
||||
The preferred method is to use the interfaces standardized by PSR-15_. This standard includes two interfaces, ``Psr\Http\Server\RequestHandlerInterface`` and ``Psr\Http\Server\MiddlewareInterface``.
|
||||
|
||||
Use ``RequestHandlerInterface`` for individual components that generate and return responses.
|
||||
|
||||
|
|
@ -42,7 +42,7 @@ Use ``MiddlewareInterface`` for classes that interact with other middleware and
|
|||
public function process(
|
||||
ServerRequestInterface $request,
|
||||
RequestHandlerInterface $handler
|
||||
): ResponseInterface
|
||||
): ResponseInterface
|
||||
{
|
||||
|
||||
// Inspect the request to see if there is a representation on hand.
|
||||
|
|
@ -87,7 +87,7 @@ This interface serves for both handlers and middleware. It differs from the ``Ps
|
|||
|
||||
.. code-block:: php
|
||||
|
||||
function next($request, $resposnse): ResponseInterface
|
||||
function next($request, $response): ResponseInterface
|
||||
|
||||
Call ``$next`` and pass ``$request`` and ``$response`` to forward the request to the next handler. ``$next`` will return the response from the handler. Here's the cache example above as a ``WellRESTed\MiddlewareInterface``.
|
||||
|
||||
|
|
@ -96,11 +96,11 @@ Call ``$next`` and pass ``$request`` and ``$response`` to forward the request to
|
|||
class CacheMiddleware implements WellRESTed\MiddlewareInterface
|
||||
{
|
||||
public function __invoke(
|
||||
ServerRequestInterface $request,
|
||||
ResponseInterface $response,
|
||||
ServerRequestInterface $request,
|
||||
ResponseInterface $response,
|
||||
$next
|
||||
) {
|
||||
|
||||
|
||||
// Inspect the request to see if there is a representation on hand.
|
||||
$representation = $this->getCachedRepresentation($request);
|
||||
if ($representation !== null) {
|
||||
|
|
@ -163,7 +163,7 @@ The best method is to use a function that returns an instance of your handler. T
|
|||
|
||||
.. code-block:: php
|
||||
|
||||
$router->register("GET,PUT,DELETE", "/widgets/{id}",
|
||||
$router->register("GET,PUT,DELETE", "/widgets/{id}",
|
||||
function () { return new App\WidgetHandler() }
|
||||
);
|
||||
|
||||
|
|
@ -202,11 +202,11 @@ For handlers that do not require any arguments passed to the constructor, you ma
|
|||
|
||||
.. code-block:: php
|
||||
|
||||
$router->register("GET,PUT,DELETE", "/widgets/{id}", App\WidgetHandler::class);
|
||||
$router->register('GET,PUT,DELETE', '/widgets/{id}', App\WidgetHandler::class);
|
||||
// ... or ...
|
||||
$router->register("GET,PUT,DELETE", "/widgets/{id}", 'App\\WidgetHandler');
|
||||
|
||||
The class is not loaded, and no instances are created, until the route is matched and dispatched. However, the drawback to this approach is the there is no way to pass any arguments to the contructor.
|
||||
$router->register('GET,PUT,DELETE', '/widgets/{id}', 'App\\WidgetHandler');
|
||||
|
||||
The class is not loaded, and no instances are created, until the route is matched and dispatched. However, the drawback to this approach is the there is no way to pass any arguments to the constructor.
|
||||
|
||||
Array
|
||||
-----
|
||||
|
|
@ -218,7 +218,7 @@ For example, imagine if we had a Pimple_ container with these services:
|
|||
.. code-block:: php
|
||||
|
||||
$c['authMiddleware'] // Ensures the user is logged in
|
||||
$c['cacheMiddlware'] // Provides a cached response if able
|
||||
$c['cacheMiddleware'] // Provides a cached response if able
|
||||
$c['widgetHandler'] // Provides a widget representation
|
||||
|
||||
We could provide these as a sequence by using an ``array``.
|
||||
|
|
@ -227,7 +227,7 @@ We could provide these as a sequence by using an ``array``.
|
|||
|
||||
$router->register('GET', '/widgets/{id}', [
|
||||
$c['authMiddleware'],
|
||||
$c['cacheMiddlware'],
|
||||
$c['cacheMiddleware'],
|
||||
$c['widgetHandler']
|
||||
]);
|
||||
|
||||
|
|
|
|||
|
|
@ -288,11 +288,11 @@ Error Responses
|
|||
|
||||
Then a router is able to locate a route that matches the path, but that route doesn't support the request's method, the router will respond ``405 Method Not Allowed``.
|
||||
|
||||
When a router is unable to match the route, it will delegate to the next middleware.
|
||||
When a router is unable to match the route, it will delegate to the next middleware.
|
||||
|
||||
.. note::
|
||||
|
||||
When no route matches, the Router will delegate to the next middleware in the server. This is a change from previous versions of WellRESTed where there Router would return a 404 Not Found reponse. This new behaviour allows a servers to have multiple routers.
|
||||
When no route matches, the Router will delegate to the next middleware in the server. This is a change from previous versions of WellRESTed where there Router would return a 404 Not Found response. This new behaviour allows a servers to have multiple routers.
|
||||
|
||||
Router-specific Middleware
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
@ -315,9 +315,9 @@ This feature allows you to build a site where some sections use certain middlewa
|
|||
|
||||
// Add the "private" router.
|
||||
$private = $server->createRouter();
|
||||
// Authorizaiton middleware checks for an Authorization header and
|
||||
// Authorization middleware checks for an Authorization header and
|
||||
// responds 401 when the header is missing or invalid.
|
||||
$private->add($authorizaitonMiddleware);
|
||||
$private->add($authorizationMiddleware);
|
||||
$private->register('GET', '/secret', $secretHandler);
|
||||
$private->register('GET', '/members-only', $otherHandler);
|
||||
$server->add($private);
|
||||
|
|
|
|||
Loading…
Reference in New Issue