Typed Request and Response

Question

PHP

Does it make sense when developing in PHP to implement strongly typed objects for request and response?

For example, if we know that the action will receive $_POST with the user_id, post_title, post_text, post_tags[] keys, then we can create a class of the AddPostRequest type, inheriting it from the Request base class, specifying fields, validation for them, access methods.

Or if we know that we need to pass the status, posts, user fields to the template, then we create a special ViewPostsResponse extends Response object, add helpers, validation, fill in the fields and send it to the template. The template knows only about this object and that's it. A kind of layer-container between the controller and the template.

With this, we specify the format for data exchange between parts of the application, we can save the logic for processing requests and responses in these objects, and more clearly distinguish between roles in the application.

On the other hand, the introduction of additional entities can complicate the code and introduce additional errors. If they are not applied correctly, then on the contrary, the boundaries of roles between parts of the application can be blurred.

Is it worth taking a similar approach when developing in PHP? In other technologies, there are definitely typed Views, most likely there are typed queries too.

Answer 1

IMHO, the task of a request is to accept incoming data (POST / GET / COOKIE and other headers), initiate the launch of the desired controller method, and return the request with the result. Accordingly, all logic (validation, queries to the database, etc.) should be in the controller, but not the request. Request is a utility class, and it makes sense to split it into subclasses if various options for processing an incoming request are possible, but not to adapt to the business logic in any way.

Answer 2

Writing classes for req and res is overengineering. Validation is enough, it can be placed either in the controller or in the model, depending on your preferences.

Answer 3

In my opinion, it makes no sense, the request should only describe the HTTP logic and should not know anything about the specifics of the data transmitted in it. The request must be validated by the validator after routing.

Answer 4

And you can also create BaseRequest and BaseResponse for greater importance and write something in common there, and then inherit Request and Response from them, and so on. It is also possible to compose some other intermediary class to connect these objects, and for greater importance, make all the parameters that the Request can receive objects, and already write validation in them for each. After all, this is OOP, right? ;-)

Answer 5

The problem is that polymorphism will be clumsy there. To determine which class instance to instantiate, you must first parse the contents of the request, which you design should be done in one of the child classes.
Classes that are responsible for processing different types of requests should be separate, but reception and analysis, IMHO - multiplexer + filter = 1, 2 classes (which do not depend on the contents of the package).

Answer 6

In general, there is something reasonable moments. But in itself, typing a post is not yet an object, and with validation, the business logic is drawn to the form. True, there are cases when there are get-parameters, but you don’t really need to validate them (some view parameters or say ?mode=debug), then there will be no form. In general, it can get confusing. I think all that is needed is the validation of the presence of the necessary, the absence of unnecessary post parameters, this is the method of the base Request, and there is no need for successors.
Have you looked at how it is implemented in popular frameworks?

Answer 7

By the way, I'm thinking about it right now. This has its advantages:
* no need to validate data in the controller;
* in turn, the controller will acquire an interface.
But the complexity, of course, increases significantly. For example, when we do not know in advance the complete list of data that we need, and this list itself will depend on the data that is in the request.