Generic Request/Response Interfaces

[Dracony]

So I was working on having both HTTP and CLI controllers in an app, and stumbled across a few things that might be a good idea for a PSR. I'm not the best guy to explain my thoughts verbally so please ask question if it's not clear =)

So the goal is to be able to reuse as much code as possible when handling different kinds of interaction mediums ( in my case HTTP and CLI ).

Initially I thought it was easy:

• Put all logic in models
• Have medium-specific controllers ( CLIController and HTTPController) that would operate those models
  

The lesser problem with this approach is some code duplication in controllers, and one can live with that.

But the bigger problem is having components that rely on a specific medium like Cookies and Session.

So my initial idea was to have a medium agnostic Persistance interface, which would use Cookies for HTTP and emulate same functionality using environment variables in CLI.

This for example  would allow me for example to allow users to authenticate with the same Auth component even when using CLI, with the authorization persisting across calls:

>php cli.php login <user> <pass>
>php cli.php getProfile

My ultimate goal then would be to create an interactive dialog style communication with the app.

So this got me thinking I can take it one step further and provide a common medium-agnostic Request interface, which is not that hard because it pretty much boils down to getParam().

And a semi-agnostic Response interface with some template rendering.

Having these Request, Response and Persistence interfaces I then would be able to reuse pretty much all the code regardless of the medium used.

So yeah, what do you guys think?

[Evert Pot]

On 2015-02-17 5:15 AM, Dracony wrote:
> So I was working on having both HTTP and CLI controllers in an app, and
> stumbled across a few things that might be a good idea for a PSR. I'm
> not the best guy to explain my thoughts verbally so please ask question
> if it's not clear =)
>
> So the goal is to be able to reuse as much code as possible when
> handling different kinds of interaction mediums ( in my case HTTP and CLI ).
>
> Initially I thought it was easy:
>

> * Put all logic in models
> * Have medium-specific controllers ( CLIController and HTTPController)

> that would operate those models
>
> The lesser problem with this approach is some code duplication in
> controllers, and one can live with that.
> But the bigger problem is having components that rely on a specific

> medium like /Cookies/ and /Session/.

>
> So my initial idea was to have a medium agnostic

> /Persistance/ interface, which would use Cookies for HTTP and emulate

> same functionality using environment variables in CLI.
> This for example would allow me for example to allow users to
> authenticate with the same Auth component even when using CLI, with the
> authorization persisting across calls:
>
> |
>>php cli.php login <user><pass>
>>php cli.php getProfile
> |
>
> My ultimate goal then would be to create an interactive dialog style
> communication with the app.
>
> So this got me thinking I can take it one step further and provide a
> common medium-agnostic Request interface, which is not that hard because
> it pretty much boils down to getParam().
> And a semi-agnostic Response interface with some template rendering.
>
> Having these Request, Response and Persistence interfaces I then would
> be able to reuse pretty much all the code regardless of the medium used.

Your goal shouldn't be to try to abstract the Request into something
that works in non-http contexts, but rather create something else on top
that *uses* http requests for http contexts.

Evert

[Dracony]

My intent was abstracting the entire medium, not just the Request. E.g. the Persistence interface I mentioned