PWF Endpoints

Besides of untrusted data from client's HTTP requests, endpoints should have access to trusted server's data, which can come from following resources:

• Hardcoded in file which should be in a form of external data file (php, json, neon, csv, xml and others). These data should be clearly separated from the rest of the code (otherwise they would represent Magic strings/numbers antipattern) and constant (otherwise it is Big ball of mud antipattern). Possible solution for php format is to have CONFIG constant array (which conveniently acts like superglobal read-only array).
• Provided by service (like DBMS). These data are dynamically created (may change in time) in various formats.
• Session (request persistent) data are accumulated within the user's interaction with the web.

Let's define three classes of endpoints:

• statefull endpoint with all three types of trusted input.
• stateless endpoint: the input is fully defined by HTTP request. This happens if session data are not used.
• idempotent endpoint: the output is fully defined by HTTP request. This happens if session and service-based data are not used.

In these trusted resources there should be Client metadata: the format in which the client's data are validated. This is not enough for secure requests, the data also needs to be consistent. The Consistency metadata are usually a set of rules/tests. Consistency metadata may be dynamic (i.e. user gaining priviledges in time). If responsibility is involved in data handling, valid and consistent data are not automatically Trusted data. In that case we need to check them outside of scope of consistency rules by using TLS (certificate check), dual security logging or by filtering network attacks on lower layer protocol. Communication security is usually not dependent on the web workflow and can be delegated to proxies which mark data as trusted.

• example of invalid data (meta) {deposit: int}, (data) {deposit: 'a lot'}
• example of valid inconsistent data (meta) {deposit: int, maxDeposit: int} (data) {deposit: 30, maxDeposit: 20} (consistency rule) assert(deposit<=maxDeposit)

If client's data are in valid format and consistent with data rules, the endpoints may optionally do some postprocessing to transform them to fit into small set of data models input (which will be discussed later).

This is expressed in the following diagram:

If the valid consistent request can not be obtained, it usually leads to one or a few error workflows. Therefore the endpoint should not defensively test the input in every function, but rather raise Exception which will auto-redirect it to error handling unit. The suggested exceptions are:

• PWF_UNSUPPORTED_HTTP_METHOD if the HTTP Request method is unexpected.
• PWF_MISSING_TRUSTED_DATASOURCE if some trusted datasource is unavailable.
• PWF_INVALID_SERVICE_DATA if some service doesn't return expected data (hardcoded data are trusted to avoid overzealous checking).
• PWF_INVALID_REQUEST if the client's request contains invalid data.
• PWF_INCONSISTENT_REQUEST if the combination of trusted and client's data is inconsistent with input rules.
• PWF_UNTRUSTED_REQUEST if security proxies are involved.

Only endpoints should handle client's requests. Only error handlers should handle errors. Other framework units should trust the valid consistent trusted request, they should not test it again, they should focus on the workflow. In procedural paradigm the program has phases and testing outside of testing phase is an antipattern resembling God object in OOP.

In the next step we will discuss the structure of the endpoints.