PHP Standards Recommendations (PSR)
The PHP Standard Recommendation (PSR) is a PHP specification published by the PHP Framework Interop Group. It serves the standardization of programming concepts in PHP. Each PSR is suggested by members and voted according to an established protocol to act consistently and in line with their agreed-upon processes.
We will present some of the most important standards. The standards in the draft will not be shown.
PSR-1 (Basic Coding Standard)
⦁ Files MUST use only UTF-8 without BOM for PHP code.
⦁ Namespaces and classes MUST follow an “autoloading” PSR: [PSR-0, PSR-4].
⦁ Class names MUST be declared in StudlyCaps.
⦁ Class constants MUST be declared in all upper case with underscore separators.
⦁ Method names MUST be declared in camelCase.
⦁ Files MUST use only <?php and <?= tags.
PSR-3 (Logger Interface)
The LoggerInterface exposes eight methods to write logs to the eight levels (debug, info, notice, warning, error, critical, alert, emergency).
PSR-4 (Autoloading Standard)
A fully qualified class name has the following form:
The fully qualified class name MUST have a top-level namespace name, also known as a “vendor namespace”.
⦁ The fully qualified class name MAY have one or more sub-namespace names.
⦁ The fully qualified class name MUST have a terminating class name.
⦁ Underscores have no special meaning in any portion of the fully qualified class name.
⦁ Alphabetic characters in the fully qualified class name MAY be any combination of lower case and upper case.
⦁ All class names MUST be referenced in a case-sensitive fashion.
PSR-6 (Caching Interface)
Caching is a common way to improve the performance of any project, making caching libraries one of the most common features of many frameworks and libraries. This has lead to a situation where many libraries roll their own caching libraries, with various levels of functionality. These differences are causing developers to have to learn multiple systems that may or may not provide the functionality they need. In addition, the developers of caching libraries themselves face a choice between only supporting a limited number of frameworks or creating a large number of adapter classes.
PSR-7 (HTTP Message Interface)
Every HTTP request message has a specific form:
POST /path HTTP/1.1
The first line of a request is the “request line”, and contains, in order, the HTTP request method, the request-target (usually either an absolute URI or a path on the webserver), and the HTTP protocol version. This is followed by one or more HTTP headers, an empty line, and the message body.
HTTP response messages have a similar structure:
HTTP/1.1 200 OK
This is the response body
PSR-11 (Container Interface)
The Psr\Container\ContainerInterface exposes two methods: get and has.
⦁ get takes one mandatory parameter: an entry identifier. It must be a string. A call to get can return anything, or throws an exception if the identifier is not known to the container. Two successive calls to get with the same identifier should return the same value.
⦁ has takes one unique parameter: an entry identifier. It MUST return true if an entry identifier is known to the container and false if it is not. has($id) returning true does not mean that get($id) will not throw an exception. It does however mean that get($id) will not throw a NotFoundException.
PSR-16 (Simple Cache)
PSR-16 gives us a layer of simplification and ease of use on top of PSR-6 for most cache operations (get, set, has) and provides an adapter class that allows PSR-16 operations on PSR-6 cache objects. Maybe the biggest benefit from PSR-16 is the support of multiple-key operations speeding up development time as processing speed by eliminating round-trip delay time. It was designed to be only a layer of convenience and a tool to speed up the development process.