Download the PHP package phoneburner/http-tortilla without Composer
On this page you can find all versions of the php package phoneburner/http-tortilla. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download phoneburner/http-tortilla
More information about phoneburner/http-tortilla
Files in phoneburner/http-tortilla
Package http-tortilla
Short Description Set of traits that make wrapping PSR-7 objects easier.
License MIT
Informations about the package http-tortilla
HTTP Tortilla - HTTP Message (PSR-7) Wrapper
This library provides a simple set of traits to allow wrapping (or decoration) of various PSR-7 classes. Wrapping the classes allows easy addition of convenience methods while maintaining compatibility with code that relies on the underlying PSR interfaces.
Requirements
This package will work with either v1.1 or v2.0 of the PSR-7 interfaces, but
does not provide the actual implementations to be wrapped. Those can be found
in other packages, e.g guzzlehttp/psr-7
or Laminas Diactoros.
As the traits provide the interface methods, they also enhance the method signatures with type hints and return values. Because of that PHP 8.2 or higher is required.
Usage
To add behaviour to a PSR7 object that implements MessageInterface
or
one of its subclasses use
the matching wrapper trait, and call
setMessage($message)
to wrap the target object.
Once setMessage($message)
is called all interface methods will be
proxied to the original object. Any of those methods can be redefined,
however, most usage will probably be adding additional convenience
methods to the object.
Because most with*()
methods will likely evolve the wrapped object
as the method is proxied to that underlying object. To maintain the
wrapping through various calls to with*()
, setFactory($callable)
allows a callable that returns a wrapped object when given the product
of the underlying with*()
message.
If the underlying object needs to be accessed, getMessage()
may be
used.
Example
Perhaps it would be convenient to access query parameters as a
collection (and not the interface's array
):
Or perhaps the underlying library doesn't handle parsing JSON requests: