Databases
StackOverflow2013
Postsdbo
POWhat are the benefits of routers when the URI can be parsed dynamically?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat are the benefits of routers when the URI can be parsed dynamically?
    primarykey
    data
    text
    <p>I'm trying to make an architectural decision and I'm worried that I'm missing something big about URL routing / mapping when it comes to designing a basic REST API / framework. </p> <p>Creating routing classes and such that is typically seen in REST API frameworks, that require one to manually map a URL to a class, and a class method (action), kind of seems like a failure to encapsulate the problem. When this can all be determed by parsing the URL dynamically and having an automatic router or front page controller.</p> <p><code>GET https://api.example.com/companies/</code></p> <p>Collection resource that gets a list of all companies.</p> <p><code>GET https://api.example.com/companies/1</code></p> <p>Fetches a single company by ID.</p> <p>Which all seems to follow the template:<code>https://api.example.com/&lt;controller&gt;/&lt;parameter&gt;/</code></p> <p><strong>Benefit 1: URL Decoupling and Abstraction</strong></p> <p>I assume one of the on paper benefits of having a typical routing class, is that you can decouple or abstract a URL from a resource / physical class. So you could have arbitrary URL's like <code>GET https://api.example.com/poo/</code> instead of <code>GET https://api.example.com/companies/</code> that fetches all the companies if you felt like it.</p> <p>But in almost every example and use-case I've seen, <strong>the desire is to have a URL that matches the desired controller</strong>, action and parameters, 1 : 1.</p> <p>Another possible benefit, is that collection resources within a resource, or nested resources, might be easier to achieve with URL mapping and typical routers. For example:</p> <p><code>GET https://api.example.com/companies/1/users/</code></p> <p>OR </p> <p><code>GET https://api.example.com/companies/1/users/1/</code></p> <p>Could be quite challenging to come up with a paradigm that can dynamically parse this to know what controller to call in order to get the data, what parameters to use, and where to use them. But I think I have come up with a standard way that could make this work dynamically.</p> <p>Whereas manually mapping this would be easy.</p> <p>I could just re-route <code>GET https://api.example.com/companies/1/users/</code> to the users controller instead of the companies controller, bypassing it, and just set the parameter "1" to be the company id for the WHERE clause.</p> <p><strong>Benefit 1.1: No Ties to Physical Paths</strong></p> <p>An addendum to benefit 1, would be that a developer could completely change the URL scheme and folder structure, without affecting the API, because everything is mapped abstractly. If I choose to move files, folders, classes, or rename them, it should just be a matter of changing the mapping / routing.</p> <p>But still don't really get this benefit either, because even if you had to move your entire API to another location, a trivial change in .htaccess with fix this immediately.</p> <p>So this:</p> <p><code>GET https://api.example.com/companies/</code></p> <p>TO</p> <p><code>GET https://api.example.com/v1/companies/</code></p> <p>Would not impact code, even in the slightest. Even with a dynamic router.</p> <p><strong>Benefit 2: Control Over What Functionality is Exposed</strong></p> <p>Another benefit I imagine a typical router class gives you, over a dynamic router that just interprets and parses the URL, is control over exactly what functionality you want to expose to the API consumer. If you just do everything dynamically, you're kind of dropping your pants, automatically giving your consumer access to the entire system.</p> <p>I see this as a possible benefit for the dynamic router, as you wouldn't then have to manually define and map all your routes to resources. It's all there, automatically. To solve the exposure problem, I would probably do the opposite by defining a blacklist of what functionality the API consumer shouldn't be allowed to use. I might be more time effective, defining a blacklist, then defining each and every usable resource with mapping. Then again, it's riskier too I suppose. You could even do a whitelist... which is similar to a typical router, but you wouldn't need any extended logic at all. It's just a list of URL's that the system would check, before passing the URL to the dynamic router. Or it could just be a private property of the dynamic router class.</p> <p><strong>Benefit 3: When HTTP Methods Don't Quite Fit the Bill</strong></p> <p>One case where I see a typical routers shining, is where you need to execute an action, that conflicts with an existing resource. Let me explain.</p> <p>Say you want to authenticate a user, by running the login function within your user class. But now, you can't execute <code>POST https://api.example.com/users/</code> with credentials, because that is reserved for adding a new user. Instead, you need to somehow run the login method in your user class. You don't want to use <code>POST https://api.example.com/users/login/</code> either, because then you're using verbs other than the HTTP methods. However, with a typical router, you can just map this directly, as said before. Easy.</p> <p><code> url =&gt; "https://api.example.com/tenant/"<br> Controller =&gt; "users"<br> Action =&gt; "login"<br> Params =&gt; "api_key, api_secret" </code></p> <p>But, once again, I see an plausible alternative. I could just create another controller, called login or tenant, that instantiates my user controller, and runs the login function. So a consumer could just <code>POST https://api.example.com/tenant/</code>, with credentials, and blam. Authentication.</p> <p>Although, to get this alternative to work, I would have to physically create another controller, when with a URL mapper, I wouldn't need to. But this seperation of concerns, functionality and resources, is quite nice too. But, maybe that's the main trade off, would you rather just define a URL route, or have to create new classes for each nuance you encounter?</p> <p><strong>What am I not seeing, or understanding? Am I missing a core concept here and just ignorant? Are there more benefits to having typical URL mapping and routing classes and functionality, that I'm just not aware of, or have I pretty much got this?</strong></p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USDaniel Carvalho
    1. USDaniel Carvalho
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhat are the benefits of routers when the URI can be parsed dynamically?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POWhat are the benefits of routers when the URI can be parsed dynamically?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWhat are the benefits of routers when the URI can be parsed dynamically?
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI would like to help but it is too long to read , can you summarize it ?
      singulars
      1. POWhat are the benefits of routers when the URI can be parsed dynamically?
      1. USsino
    2. COI asked what is the potential benefits of having typical routers vs a dynamic router / just parsing the URL dynamically. What potential pitfalls would typical routers help me avoid, other than what I've stated above?
      singulars
      1. POWhat are the benefits of routers when the URI can be parsed dynamically?
      1. USDaniel Carvalho
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload