[erlang-questions] Cowboy routes with Method as a condition

Vladimir Dronnikov dronnikov@REDACTED
Wed Feb 13 15:44:05 CET 2013


Max, one could insert a middleware before cowboy_router which mangle URI to
be Method/URI and then in the router rules treat Method chunk as binding --
hence, method constraints.

--Vladimir

On Wed, Feb 13, 2013 at 3:02 PM, Loïc Hoguin <essen@REDACTED> wrote:

> The HTTP RFC says this on page 6:
>
>    It builds on the discipline of reference
>    provided by the Uniform Resource Identifier (URI) [3], as a location
>    (URL) [4] or name (URN) [20], for indicating the resource to which a
>    method is to be applied.
>
> It then defines resources as follow on page 9:
>
>       A network data object or service that can be identified by a URI,
>       as defined in section 3.2. Resources may be available in multiple
>       representations (e.g. multiple languages, data formats, size, and
>       resolutions) or vary in other ways.
>
> It then describes how to locate resources in many of the following
> sections, starting with section 3.2 page 18.
>
> Cowboy implements this. It maps URIs to resources. It makes absolutely no
> assumptions as to how your resources operate. Anything that is part of the
> URI can and will be used to locate resources. But if it's not part of the
> URI, then it's not something used to find resources as defined by the HTTP
> standard, which makes it out of the scope of the project.
>
> It still provides you with many ways to plug yourself into Cowboy to
> achieve what you want, which include:
>
>  *  Middleware
>  *  Protocol upgrade (what REST handlers are doing)
>  *  init/3 based method dispatching
>  *  handle/2 based method dispatching
>
> And I'm sure there's more.
>
>
> On 02/13/2013 11:42 AM, Max Lapshin wrote:
>
>> Loic, my idea about routing is that router is a piece of software that
>> translates input http request into presentation, convenient for handler
>> and selects proper handler for this with proper arguments.
>>
>> I don't understand your logic: you allow to run regexp to validate if
>> constraint is a digit:   "/users/:user_id", [{user_id,fun() -> .. end}],
>> but you are strongly against validating method in constraints.
>>
>> You tell me to spread logic between your router and my router. You tell
>> me that I need to use two routers that will somehow interfere with each
>> other. What is the idea? I really don't understand.
>>
>>
>> On Wed, Feb 13, 2013 at 2:39 PM, Loïc Hoguin <essen@REDACTED
>> <mailto:essen@REDACTED>> wrote:
>>
>>     On 02/13/2013 11:34 AM, Max Lapshin wrote:
>>
>>         handle(Req, State) ->
>>               handle_method(cowboy_req:get(_**_method, Req), Req, State).
>>
>>           will require
>>
>>
>>         handle_method(<<"GET">>, Req, State)
>>         handle_method(<<"DELETE">>, Req, State)
>>         handle_method(Other, Req, State)
>>             here we copy from module to module default reply on "method
>> not
>>         supported" or 404, whatever we choose.
>>
>>
>>         with method constraints code can look so:
>>
>>
>>         init(_, Req, [Action]) ->
>>            {ok, Req, Action}.
>>
>>
>>         handle(Req, show) ->
>>             ..
>>
>>         handle(Req, destroy) ->
>>             ..
>>
>>         handle(Req, list) ->
>>             ..
>>             .
>>
>>         And no "default handler" because it is not required. Only good
>>         requests
>>         can pass to this handler.
>>
>>
>>     Then in your init function do something like
>>     your_lib:route_method(Req) which returns {ok, Req, Action} if it's
>>     good or {shutdown, ...} if not? It'll do exactly what you just said.
>>
>>
>>     --
>>     Loïc Hoguin
>>     Erlang Cowboy
>>     Nine Nines
>>     http://ninenines.eu
>>
>>
>>
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130213/425846eb/attachment.htm>


More information about the erlang-questions mailing list