Feature request: routing handler about ileastic HOT 9 CLOSED

Absolutely! I have not made anything in the request yet - please stay tuned. And thank you for your feedback

from ileastic.

As a follow up, I had an idea for routing parts.

For example, if you'd like to make a dynamic rest API: the URL could be split up into parts.

getURLPart(request.url:1); //where request.url = '/id/101', would return '101'

from ileastic.

Just to keep notes. request.url and request.resource were both added in 46e327e.

• 46e327e#diff-31f80c15f7e9f88d7f242068acadb407R148
• 46e327e#diff-31f80c15f7e9f88d7f242068acadb407R160

from ileastic.

Each ILEastic definitely needs to handle multiple endpoints. It would scale really bad if you need to have one service running for each endpoint.

I think we need to split the registering of an endpoint from the starting of the server (as it is now with the il_listen function).

The minimum parts for adding an endpoint should be the address of the endpoint, url and HTTP method.

In modern frameworks the available content types (for the return value) is also part of the routing.

from ileastic.

For example, if you'd like to make a dynamic rest API: the URL could be split up into parts.

This should be no feature but a default requirement to the framework. It is not possible to build a decent API without accessing the single parts of the URL.

from ileastic.

Partly solved - routing is added, but picking the parameters are still missing

from ileastic.

working on the "parameter pickup" now ...

from ileastic.

Path segments can now be retrieved by index, see il_getRequestSegmentByIndex() . Can we close this issue?

from ileastic.

Yes let's close it: Now there is two options to the solution. Your @m1h43l il_getRequestSegmentByIndex() and my callback solution with regex. They both server a their own purpose. Great work @m1h43l !!

from ileastic.