PSR-7 Query Concerns

[Woody Gilk]

I see a major flaw in PSR-7 that I would like to raise for discussion.

A common need for any HTTP manipulation is modifying existing query parameters. For example, modifying the a URL used for pagination, we might do this:

```

$url = $url->withQueryParams(array('page' => $page + 1));

```

Another common example might be creating HTTP requests for API calls:

```

$request = $request->withQueryParams(array('scopes' => implode(' ', $scopes)));

```

As it stands right now with PSR-7, I don't see any possible way to do this with the current interfaces and I would strongly prefer not to have to implement this code myself.

Regards,

-Woody

[Matthew Weier O'Phinney]

The temptation when building an interface is to provide *all* the
convenience methods. The difficulty in designing an API is knowing
when you have *enough*.

We have deliberately stayed away from adding convenience methods such
as the above because they are not absolutely necessary to model the
URI. While they could be helpful, at the base level, providing the
query string is _enough_.

What we are encouraging is the creation of utilities that will help
with scenarios such as these. As an example, Beau Simensen has been
working on a cookie implementation that deals with the entire cookie
lifecycle of a request, from accepting them to re-emitting them. At
their essence, cookies are simply headers, and PSR-7 deals with them
as such; however, a utility class can parse and aggregate incoming
cookies from the ServerRequest, provide cookie access with default
values, allow specifying TTL and path, etc., and then emit appropriate
header values for injection into the ResponseInterface.

I can see something similar for things like the query string when
dealing with a URI; that's the job of a URI *assembler* or
*generator*, but the UriInterface only needs to model the various URI
components, no more, no less. By providing a strict guideline as to
what constitutes a URI for purposes of interaction, we make
consumption predictable. If you want convenience, wrap it or create a
concrete version that provides convenience methods.

Adding methods like the above, while tempting, is inviting feature
creep into the specification. Not only that, but the type of
signatures you outline have a number of different paths, making
locking down a finite specification quite difficult. Leave that to a
utility class/function/whatever, and use that to seed the query
*string* when you're ready to generate your URI.

--
Matthew Weier O'Phinney
mweiero...@gmail.com
https://mwop.net/

[Dracony]

I am with Matthew on this one. The interfaces are kind of big anyway, especially the ServerRequest one which descends from two others, I don't think that adding more methods would be a good idea. 

To me these interfaces will be used as internal DTOs my own classes will wrap around. And I highly recommend that approach: create your own Uri class that wraps around the PSR UriInterface and allows versatile helper methods. Then when read just extract the actual UriInterface implementation and pass it along.

[Lukas Kahwe Smith]

> On 22 Apr 2015, at 10:48, Dracony <draco...@gmail.com> wrote:
>
> I am with Matthew on this one. The interfaces are kind of big anyway, especially the ServerRequest one which descends from two others, I don't think that adding more methods would be a good idea.
> To me these interfaces will be used as internal DTOs my own classes will wrap around. And I highly recommend that approach: create your own Uri class that wraps around the PSR UriInterface and allows versatile helper methods. Then when read just extract the actual UriInterface implementation and pass it along.

More importantly such "syntax sugar" libraries will be framework/library agnostic thanks to PSR-7. Furthermore, if it becomes clear that such "syntax sugar" library need to do too much business logic which will result in too many alternative libraries competing with slightly varying interfaces (but widely different algorithms), then we can always do another more focused PSR to handle this.

regards,
Lukas