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

[Vladimir Dronnikov]

May be this could help: https://github.com/dvv/stable#cowboy_mrouter



On Wed, Feb 13, 2013 at 6:44 PM, Vladimir Dronnikov <dronnikov@REDACTED>wrote:

> 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/20130214/bbfb4888/attachment.htm>