Why do these routes collide?

[WarrenN1]

I am confused as to why these 2 routes collide:
GET /api/cart_items/<cart_item_id> collides with (read_account_services_by_seller_id) GET /api/<seller_id>/services

• cart_item_id : Uuid
• service_id : AccountId

AccountId routing is done via the following pattern:
"{}-{}", self.id, self.class
For example:
f2717522-fd53-4bba-a2e8-daa054ed53ed-seller
Where:

• self.id = Uuid
• self.class = 1 of 2 options String: {"buyer", "seller"}

Why do I need to set the priority on these manually?

My thought is that if something formatted as GET /api/cart_items/<cart_item_id> will never succeed on GET /api/<seller_id>/services and vice versa as Uuid and AccountID serialize differently.

[SergioBenitez]

GET /api/cart_items/services would match both routes if allowed. We can't peek into the implementation of the parameter types, and matching can't consider them given their dynamic nature.

[WarrenN1]

Got it. So even though AccountId is a parameter of the function that makes up the route, because the routing system is not aware that cart_items is an invalid cast to AccountID it throws an error? Is my understanding correct?

[WarrenN1]

@SergioBenitez For speed purposes, should dynamic parts of the route always come later?

For example if I have 3 routes:

<account_id>/cart_items
<account_id>/checkout
/number_page

WHERE:
account_id : AccountId
number : i32

Under the hood, how does the rocket decision tree work for checking the routes? Does it recognize that <account_id>/checkout and <account_id>/cart_items both have account_id as type AccountId?
For example: if I submit 32/test does the process function as follows:

1. Test <account_id>/cart_items. The 1st segment fails for <account_id> so it fails. Then test if it parses properly for <account_id>/checkout and then <number>/number_page, fails and then produces an error.
   OR
2. Realize that <account_id> is of type AccountId. So if the 1st segment does not parse properly to AccountID, it knows after checking <account_id>/cart_items not to test <account_id>/checkout and instantly tries /number_page, fails and then produces an error.

Logically each account has elements to it, so organizing the paths in a folder-esk way is nice in the sense that I can imagine it as:

Warren/
Sergio/

But if that causes multiple parsings of <account_id> then I would opt for a different layout as this will slow down the system.

[SergioBenitez]

No, the router is smarter than that. There is a distinction between "matching" a route and calling its handler. You can read about matching here. If a route matches, only then is its handler called. You can read about calling handlers here.

In short, in your example, only one of those routes will match a given request, and none of the parameter guards (AccountId, i32) will be invoked until a match occurs. In other words, the matching phase happens first, which will never invoke guards, and then the matching routes' handler(s) are called.

Realize that <account_id> is of type AccountId.

Typing isn't used for matching, ever.

So if the 1st segment does not parse properly to AccountID, it knows after checking <account_id>/cart_items not to test <account_id>/checkout and instantly tries /number_page, fails and then produces an error.

There is no URI that matches all of these routes, so this will never happen. But even if the routes were different such that they collide when unranked, your statement is still incorrect. AccountId could fail the first time and succeed the second time; nothing in Rust allows us to declare and assert that a function is a pure function, so using a previous failure as indication for what might happen in the future would be logically incorrect.