api - What are the benefits of routers when the URI can be parsed dynamically? -

i'm trying make architectural decision , i'm worried i'm missing big url routing / mapping when comes designing basic rest api / framework.

creating routing classes , such typically seen in rest api frameworks, require 1 manually map url class, , class method (action), kind of seems failure encapsulate problem. when can determed parsing url dynamically , having automatic router or front page controller.

get https://api.example.com/companies/

collection resource gets list of companies.

get https://api.example.com/companies/1

fetches single company id.

which seems follow template:https://api.example.com/<controller>/<parameter>/

benefit 1: url decoupling , abstraction

i assume 1 of on paper benefits of having typical routing class, can decouple or abstract url resource / physical class. have arbitrary url's get https://api.example.com/poo/ instead of get https://api.example.com/companies/ fetches companies if felt it.

but in every example , use-case i've seen, the desire have url matches desired controller, action , parameters, 1 : 1.

another possible benefit, collection resources within resource, or nested resources, might easier achieve url mapping , typical routers. example:

get https://api.example.com/companies/1/users/

or

get https://api.example.com/companies/1/users/1/

could quite challenging come paradigm can dynamically parse know controller call in order data, parameters use, , use them. think have come standard way make work dynamically.

whereas manually mapping easy.

i re-route get https://api.example.com/companies/1/users/ users controller instead of companies controller, bypassing it, , set parameter "1" company id clause.

benefit 1.1: no ties physical paths

an addendum benefit 1, developer change url scheme , folder structure, without affecting api, because mapped abstractly. if choose move files, folders, classes, or rename them, should matter of changing mapping / routing.

but still don't benefit either, because if had move entire api location, trivial change in .htaccess fix immediately.

so this:

get https://api.example.com/companies/

to

get https://api.example.com/v1/companies/

would not impact code, in slightest. dynamic router.

benefit 2: control on functionality exposed

another benefit imagine typical router class gives you, on dynamic router interprets , parses url, control on functionality want expose api consumer. if dynamically, you're kind of dropping pants, automatically giving consumer access entire system.

i see possible benefit dynamic router, wouldn't have manually define , map routes resources. it's there, automatically. solve exposure problem, opposite defining blacklist of functionality api consumer shouldn't allowed use. might more time effective, defining blacklist, defining each , every usable resource mapping. again, it's riskier suppose. whitelist... similar typical router, wouldn't need extended logic @ all. it's list of url's system check, before passing url dynamic router. or private property of dynamic router class.

benefit 3: when http methods don't quite fit bill

one case see typical routers shining, need execute action, conflicts existing resource. let me explain.

say want authenticate user, running login function within user class. now, can't execute post https://api.example.com/users/ credentials, because reserved adding new user. instead, need somehow run login method in user class. don't want use post https://api.example.com/users/login/ either, because you're using verbs other http methods. however, typical router, can map directly, said before. easy.

url => "https://api.example.com/tenant/"
controller => "users"
action => "login"
params => "api_key, api_secret"

but, once again, see plausible alternative. create controller, called login or tenant, instantiates user controller, , runs login function. consumer post https://api.example.com/tenant/, credentials, , blam. authentication.

although, alternative work, have physically create controller, when url mapper, wouldn't need to. seperation of concerns, functionality , resources, quite nice too. but, maybe that's main trade off, rather define url route, or have create new classes each nuance encounter?

what not seeing, or understanding? missing core concept here , ignorant? there more benefits having typical url mapping , routing classes , functionality, i'm not aware of, or have pretty got this?

a lot of benefits routing describe correct, , of physical mappings true. i'd throw in experience / practical information colored opinion on routers on last few years.

1. first of all, dynamic parsing of url works (most of time) when architect application according mvc design pattern. example, once built large application using kohana, hierarchical mvc framework, allows extend controllers , models sake of making nested urls. in general, makes lot of sense. there lot of times didn't make sense go build whole class , model system around need one-off urls make application more functional. there times mvc not design pattern you're using, , not defining feature of api, , routing beautiful in scenario. 1 see issue @ work playing frameworks have lot of structural freedom, such slim framework or express.js.

2. more people think, functional api have element of rpc-ness in addition to restful endpoints available consumption. , not additional functionalities make more sense consumer when they're decorating existing resource method mappings. tends happen after you've built out of application , covered of bases, , realize there couple little features you'd add in relation resource isn't doesn't cleanly fit create / read / update / delete categories. you'll know when see it.

3. it can not understated, safer not go hacking on actual structure of controllers , models, adding, removing, changing, things sole purpose of adding endpoint isn't inherently following same rules of other controller methods (api endpoints).

4. another important thing api endpoints more maleable realize. mean is, can ok structure of endpoints on monday, , on friday,you task sent down above saying need change of these api calls of other structure, , thats fine. but if have large application, requires very, significant amount of file renaming, class renaming, linkages, , sorts of breakable code when framework you're using has strict rules class naming, file naming, physical file path structure , stuff that...just imagine, changing class name make work new structure, , you've got go hunt down every line of code instantiated old class, , change it. furthermore, in scenario, said problem code tightly coupled url structure of api, , not maintainable should url needs change.

either way, ought decide whats best particular application. more use routers, more you'll see why they're useful.