adambender
commented
11 years ago I personally like the first approach cause it allows us to use a similar tactic for other headers if we want to match them later.
On Tue Apr 09 2013 at 9:44:17 AM, justinfagnani notifications@github.com wrote:
I can see a few ways of structuring the API.
One is to add an optional parameter to serve() which a HTTP method:
router.serve(resourceUrl, method: GET).listen(getResource); router.serve(resourceUrl, method: POST).listen(saveResource);
Another is to provide special streams that function as routers and have additional methods to filter by method:
router.serve(resourceUrl).get().listen(getResource); router.serve(resourceUrl).post().listen(saveResource);
The first is certainly easier to implement, mainly because the central matching logic in Router can let the request fall through to other matchers or the default stream quite easily. The second approach requires some feedback from the stream that an event didn't reach a listener.
— Reply to this email directly or view it on GitHubhttps://github.com/dart-lang/route/issues/17#issuecomment-16124806 .
I can see a few ways of structuring the API.
One is to add an optional parameter to serve() which a HTTP method:
Another is to provide special streams that function as routers and have additional methods to filter by method:
The first is certainly easier to implement, mainly because the central matching logic in Router can let the request fall through to other matchers or the default stream quite easily. The second approach requires some feedback from the stream that an event didn't reach a listener.