Open alganet opened 12 years ago
This should be moved/mentioned in the Cli component and closed here, should't it?!
I don't know yet. I've always though on Cli as a command line interface for Config. Maybe we should move Cli to Config or Foundation.
Cli responsibility is spread, hard to tell where things must go.
I'm willing to do this. There are a couple of things to figure out before then:
get users alganet
== GET /users/alganet
get users --since=2009
== GET /users/?since=2009
, though Respect\Rest will not abstract that for you. You'll need to do that on the route implementation. Additional ->env("cli")
, ->env("http"
and ->env("cgi"
can be added as routines to improve abstraction without increasing coupling.Just to make clear: this issue doesn't cover transparent HTTP/bash mapping. It allows developers to do that by providing tools to serve content in both HTTP and bash, as they're both RESTful.
We could create a CliRequest that when injected into the Router instead of the traditional Request could route things via Cli calls. Bash and linux are somewhat RESTful. An experimental mocked cli request is in the Router test suite for a long time now, but it isn't very friendly for users.
Considering a
$r->get('/users/*', 'MyUsersController')
sample route, both aHTTP GET /users/alganet
and aphp application.php get users alganet
cli route should route to the same point. Custom route verbs could be used, such as$r->install('/', 'MyInstallController');
.Much of the code from the current Request class would be moved to an AbstractRequest that would be extended to both Request and CliRequest.