Expanding on this point, we can "refactor" how we "present" this category, using laws from basic category theory, so that

   f :: (A, Request) -> B

   f :: A -> Request -> B

   f :: (A -> Request) -> B (this one isn't very useful to a programmer)

   f :: a -> Request B (by lifting a concrete Request object into a functor of the form (Request a))

etc, are all "equivalent", insofar as they merely present different interfaces to the same data.  Note that these are distinct as "presentations", but equivalent as categories ("isomorphic", up to decidability -- the one I said wasn't useful really isn't, because "as a matter of fact", we can't decidably analyze/deconstruct a function (g :: A -> Request) to produce a B).

This should make architectural decisions easy (or hard) -- once you have decided to use a category at all, you merely have to choose the presentation for the category that satisfies other requirements.