Reputation: 357
I my system, there are Employees, Designation, DesignationHierarchy. And Based on DesignationHierarchy I have EmployeeHierarchy.
I have a following REST URLs,
To access Employee,
//employees/:empployeeNo
To access Designation
//designations/:designationNo
To get Employee with Designation,
//employees/:employeeNo/designations/:designation/:id //Here I have used id of EmployeeDesignation resource because there are multiple entries for that employee with same designation for different timespans
When I say Hierarchy, it is NOT hierarchy of Employee rather Hierarchy of EmployeeDesignation resource.
To update Employee Hierarchy I have used,
//employees/:empNo/designations/:designation/:id/hierarchy
I also need a rest call to view graph of Employee Hierarchy on date, I have use following URL,
/employee/:employeeNo/designations/:designation/Hierarchy/graph?date=
I have created subresource graph under hierarchy.
These REST URLs are correct according to standard convensions?
Please correct me if wrong !!
Upvotes: 2
Views: 54
Reputation: 84864
Yes, the URIs you have suggested are perfectly valid and correct when it comes to RESTful architectural style.
The only thing I that comes to my head is that is not good practice to use too long URIs. I mean that in some cases you can shorten:
/res1/{ID1}/res2/{ID2}/res3/{ID3}/
to e.g.:
/res3/{ID3}/
Whereas it may not make a great sense in this particular example you've provided however it's worth to remember about avoid URIs that are too long.
Upvotes: 1