3

I have been tinkering with the idea of creating a routing system as a learning experience and not for some production purpose.

I have trying to decide what features are a must have and what features are best handled elsewhere in a system. I have come up with a short list of features and I would like to get some feedback on it. Are there things missing? Or are there anything that is just pure overkill? The list goes a follows:

  • Regular expression matching against URI
  • Matching HTTP request scheme
  • Matching HTTP request method
  • Checking if a request is a normal request or an AJAX request.

I have chosen to use regular expressions so that I have the possibility of using capture groups to match a dynamic URI. Regarding the overheat of regular expressions I think the worst can be reduced by producing clever expressions and only matching until a match is found.

Improve this question
6
  • For me, checking if its an ajax-request is to much. Yes, you want HTML for normal Requests and JSON for Ajax-Requests but this shouldn't matter for your controller, the data to fetch and send should be exactly the same, only the formatting differs. (Like in Symfony, if you annotate your controller with @Template and just return your data, the kernel will itself load the correct template (either bundle:controller:action.html.twig or bundle:controller:action.json.twig). – tkausl Dec 7 '14 at 5:35
  • @tkausl - Thanks for your feedback. I understand that how the data should presented isn't the routing systems responsibilty. The reason I included that was to make it easier to separate the two different request types. But thanks again. – AnotherGuy Dec 7 '14 at 13:16
  • @tkausl - I have a question to the approach you described in the first comment. To me it sounds like you perform all actions required to generate the content of response and then decide in which format to return the content in. But what if the matched route does not support an AJAX request. Then all the resources used to process the request is wasted? – AnotherGuy Dec 7 '14 at 17:37
  • Well, you can prevent ajax directly in the routing-module if you want, but at least, you should never ever route the same path to different controllers for AJAX and Non-AJAX requests. But about the "resource waste": Really, who cares? If you don't implement a ajax-call yourself, it should not happen (normally). And if someone plays with your html and do a ajax-call to a path which does not support ajax-calls, then yes, its wasted, but its exactly the same waste if he presses F5 to reload the page, isn't it? – tkausl Dec 7 '14 at 17:44
  • I can't say this for sure, but i guess in the long run, the CHECK if this path supports ajax costs more CPU-time then one or two idiots who call your path with ajax which can't respond. – tkausl Dec 7 '14 at 17:47
1

Everyone has their own wishlist for routing. Which is why so many people have looked over the landscape, decided that everyone else's routing is bad, and written a new one.

That said, the top of my wishlist includes hierarchical routing. That is, based on the start of the URL you should be able to route to a component that takes the next component and routes that as well. This has a performance benefit (you don't have to check at the top level for every URL in components we know you are not in) and also a code modularity benefit (when working on one component, you do not need to be messing with code for other ones).

And the top of the wishlist for any SEO purposes is going to include the ability to have URL rewriting where external SEO friendly URLs which are maintained in a dynamic table get remapped to internal URLs that reflect your application structure.

And esoterically at the application level, I like modular components inside of pages. Which means that inside of a top level page you might have a component for a sidebar over here, another one for an ad unit over there, and so on. If you like that design, then you might want to consider reusing your routing logic both for finding a top level URL, and for finding a component inside of your application. One of the nice things about operating this way is that you can set up components as things that return a data structure, and that data structure can be both consumed inside of your application while generating a page, or exposed as JSON for an AJAX request. However this is idiosyncratic, and don't try it if it doesn't sound interesting to you.

Improve this answer
1
  • 1
    Your hierarchical routing sounds really interesting. I work a lot with symfony but i cannot get rid of the thought, that this routing is suboptimal because first, like you mentioned, if you have a lot of paths, you'll end up checking a lot of paths you're not even in, and secondly, regex is really reeeally slow, compared to a strcmp or something like this. And now multiply the slowness of regex with the tons of paths you check. – tkausl Dec 8 '14 at 2:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.