Download the PHP package juanchosl/requestlistener without Composer

# RequestListener

Description

This library groups the definitions of the different elements involved in data transmissions such as HTTP, applying the interfaces defined in PSRS 7 and 17, adding the extra objects used and ensuring compliance with the requirements that allow to give the necessary stability To our application, being able to implement for third -party bookstores without the need to adapt our business logic to a new implementation that could modify its consumption or internal structure.

Install

Engines

The library accept two types of uses

• http requests
• console commands

Both systems parse the SERVER globals and create a ServerRequestInterface compatible element in order to unify his use across all the work flow. The user needs to prepare the response format according to the requested type. You can create you own Engine parser implementing the JuanchoSL\Contracts\EnginesInterface, only needs:

• static parse method, passing the vars to parse. Returns an EngineInterface entity
• getRequest, to retrieve the parsed ServerRequest
• sendMessage, to perform and send the compatible ResponseInterface message

HTTP requests

Create a request according to the PSR-7, the request is builded using PHP superglobals, for body contents, if content-type header is setted as application/x-www-form-urlencoded or multipart/form-data, the superglobal POST is used, for other media-types, the 'php://input' contents is readed and putted as body and parsed as a DataTranster entity and putted into parsedBody

Console commands

Create a request according to the PSR-7, the request is builded using SERVER['args'] superglobal for fill Query params and STDIN for body contents, the arguments need to have the next format: The parameter name needs to start with --, then can assign values from:

• concat with an equals sign (--name=value)
• put the value after parameter (--name value)
• if is a void parameter that don't need value, just write the parameter name (--void_parameter)
• if is a multiple values parameter, use the name all times that you need pass a value or write the name and value multiple times as a single value
  • --multiple=value1 --multiple=value2
  • --multiple value1 --multiple value2
  • --multiple value1 value2

Application

Middlewares

PRE middlewares

Enabled by default

• ValidRouteMiddleware: Check than the selected target is defined and exists
• OptionsMethodMiddleware: Return a response with the available METHODs for the selected target
• TraceMethodMiddleware: Check if the TRACE method is available for the selected target
• HeadMethodMiddleware: If the request is a HEAD method request, convert to GET, process it and remove the body before return to client

Available for use

• ValidMethodMiddleware: Check if the requested method is available, if a HEAD method is selected, we convert to a GET before check it, and remove the body from response if it is availble
• ValidMediaTypeMiddleware: Check if any accepted media-type from the request is available
• CacheMiddleware: Can enable this available middleware providing a PSR-16 SimpleCacheInterface in order to use it
• OutputCompressionMiddleware: Using this available middleware, can compress or encodig response bodies, according the Accept-Encoding client header, in br(brotli), zstd, deflate or gzip
• RateLimitMiddleware: In order to count the UNAUTHORIZED responses and block the client using SESSION for N seconds, can indicate the num of failed counts and the banned seconds

User Defined PRE middlewares

You can create and use Middlewares that implementing the PSR-15 Interfaces, according the Psr\Http\Server\MiddlewareInterface

Other available Middlewares

• CacheMiddleware: Use any compatible PSR-16 library in order to check, load and save web caches
• OutputCompressionMiddleware: Compress http responses using native libraries (deflate, gzip, zstd and brotli)
• DebugXhprofMiddleware

Request handlers

According the PSR-15, you can create and execute your own RequestHandlers

Use cases

The Application system, group the routing, methods access, and callables to be executed when the rules has been accomplished. Into the entrypoint, you need to prepare endpoints and his rules to be executed.

When you extend the UseCases provided class, a configure method is required, in order to set the valid parameters, performing an autovalidation. Actually we have available the validations in two levels, requiring and type.

The requiring mode can be:

• InputArgument::REQUIRED -> the lib check than the parameter is provided by the user
• InputArgument::OPTIONAL -> if is provided, knowing it, the lib can check the desired type

The type validations can be for:

• InputOption::VOID = 'void' ->the lib checkif is present, no value needs to be present
• InputOption::BOOL = 'bool' -> a value as string is accepted, true, "true", 1, "1", "On" for compare as bool true, and false, "false",0,"0","Off" as bool false
• InputOption::SINGLE = 'single' -> only one value is accepted
• InputOption::SINGLE_INT = 'single_int' -> only one value is accepted, and needs to be an integer value (or a string with only an integer value)
• InputOption::SINGLE_NUMBER = 'single_number' -> only one value is accepted, and needs to be a number value (or a string with only a numeric value)
• InputOption::MULTI = 'multiple' -> N values are accepted
• InputOption::MULTI_INT = 'multiple_int' -> few values are accepted, and needs to be integers values (or strings with only integers values)
• InputOption::MULTI_NUMBER = 'multiple_number' -> few values are accepted, and needs to be numeric values (or strings with only numeric values)

The callables can be:

• A Handler implementing the PSR-15 interface
• A command, extending the UseCases provided class and implementing an __invoke method with the params:
  • ServerRequestInterface
  • ResponseInterface
• A callable with format [ClassName::class, 'method_to_call']

ExampleCommand

Debug