PWF Endpoints structure

The request is defined by HTTP method and HTTP data. HTTP data can be send in the form of URL path: in that case there is usually a tool that transforms the path into HTTP GET variables equivalent. PHP server conveniently parses the data into $_GET and $_POST superglobal arrays. The values can be only of type string, null (no value) or array of these values (if the name contains square brackets). The data consists of request identifier and request parameters. The identifier is a single variable or a function that transforms multivariable identifier to single variable. This is the key for validation metadata table, i.e.

[ "login" => ["email" => "string", "password" => "string"], "setname" => ["value" => "string"], "deposit" => ["value" => "int"] ]

These data should be file hardcoded: should they be provided by a service, no request could be made if the service is unavailable. Having the HTTP request and the validation metadata, we can automate the process of validating and have valid data or exception thrown for the next phase. This approach is not suitable for POST Endpoint, because of the need for client-side and server-side check coded twice the same way in HTML/Javascript and PHP respectively. One could generate the client-side code from the server side, but then the HTML could be produced only by this generator, which is too restraining (there are many external tools for that, unaware of this need). The solution for POST Endpoint could be form name mangling,

Then we perform consistency check (if needed), which is driven by similar table, but values are functions with set of assert() calls, redirecting the phase to error handler if something is not consistent. In this phase, calling external service like database is oftentimes needed.

If the request is valid and consistent, we perform data transaction: reading or writing data the request desires.

Then the workflow process depends on endpoint type:

GET Endpoint sends the data to Page Container, which is HTML template system most of the time.
POST Endpoint sends the data to Flash Reporter and performs redirect to GET Endpoint.
BG and REST Endpoints produces plain text data using fputcsv(), json_encode() and other functions of that kind.
Ad-hoc Endpoint acts as defined by external service.

Error handlers can process the error in a general way (logging, producing 4xx, 5xx error page), redirect to fallback endpoint or halt any response in case of attack.

In the final step we will outline the Flash Reporter and the Page Container.