Lets say we have a resource structure like below
| GUID | Region | Country | State | StateDetails |
|---|---|---|---|---|
| a120c850-e296-4563-8fb9-31d0192aef75 | EMEA | FR | Normandy | Statedetails |
| 6f4b3ca6-c992-42dd-b1e3-8c8f8ba62886 | APAC | AU | New South Wales | Statedetails |
| d202b255-5fe1-4203-b4ad-3cc74f4f6986 | AMERICAS | US | California | Statedetails |
| ...etc | ...etc | ...etc | ...etc | ...etc |
Where guid is a unique identifier for a resource record
and Region is a parent for country which in turn is a parent for state and each such state has one record in the table. (region/country/state combination is unique and can act as an alternate key)
In order to display the State details json, which URL naming would be more appropriate. Are there pros and cons to each approach ?
Option 1:
http://www.xyzsamplecompany.com/insertGUIDhere
eg: http://www.xyzsamplecompany.com/6f4b3ca6-c992-42dd-b1e3-8c8f8ba62886
(or)
Option 2:
http://www.xyzsamplecompany.com/region/country/state/resource
eg: http://www.xyzsamplecompany.com/EMEA/FR/Normandy/statedetails
Listing my thoughts here.
In Option 1,
the link is immutable and relatively static. So the same URL will return same data over a long period of time. So a client (requestor) may be provided the static link which they can book mark for future use. Tomorrow if the data changes (say france decides to rename normandy to normândy) such complexity is hidden from the requestor.
However there is less transparency as to what resource we are inquiring and the complexity is hidden.
In Option 2, the hierarchy is very clearly laid out. The complexity of arriving at the correct URL is left to the client (requestor) so they need to keep track of underlying data changes.
It is transparent for any system inspecting the resource such as a monitoring tool or WAF. However with excess transparency, if an unwanted third party knows the list of states, countries, regions (which is common knowledge) then there is risk of scraping which could prove resource intensive.
