WResource routing with arguments in path (for RESTful API)
Added by Michael Schwarz about 6 years ago
Hey,
I'd like to inquire about the status of this ticket:
https://redmine.webtoolkit.eu/issues/5656
That feature would be awesome to have. I'm currently experimenting with a heavily hierarchical API, something like this:
/projects/{variant-id}/{version-id}/properties/{type-id}/...
If I'm interpreting the documentation and the forum correctly, I'm currently not able to assign separate WResource to the different levels of the API, but must have the /projects Resource handle everything by parsing pathInfo().
Is that correct?
Or is there an easier way?
Replies (4)
RE: WResource routing with arguments in path (for RESTful API) - Added by Mark Petryk about 6 years ago
What would you do instead of a single WResource deployed at "/projects" followed by parsing the pathInfo() after that?
RE: WResource routing with arguments in path (for RESTful API) - Added by Mark Petryk about 6 years ago
I mean... looking at your requirements, you'd have to have something to handle every instance of {variant-id} and {version-id} and so on...
I have a document handler, and it's deployed at "docs" and the request looks like:
/docs/{user-id}/{doc-id}/{file-name}
And it's all handled in the "/docs" WResource handler.
RE: WResource routing with arguments in path (for RESTful API) - Added by Michael Schwarz about 6 years ago
Mark Petryk wrote:
I mean... looking at your requirements, you'd have to have something to handle every instance of {variant-id} and {version-id} and so on...
Exactly right. Because they are all resources in their own right, nested into each other (in OO terms it would be a composition).
So if I request
/projects/{variant-id}/{version-id}/properties
I expect a reply carrying information about properties, NOT projects.
I just have to give the resource path of project, variant and version because that is where my properties happen to reside.
Ergo, having the projects resource handle this request for property information would not be clean design. (Although it could be done and would be invisible to users of the API.)
I have a document handler, and it's deployed at "docs" and the request looks like:
/docs/{user-id}/{doc-id}/{file-name}
And it's all handled in the "/docs" WResource handler.
So... if I'd request, say
/docs/{user-id}
- what kind of response would I get?
If your answer is "user information", then {user-id} is a true resource and should be internally handled as such. (I'd wonder why your users are children of documents, but that would be a whole other issue).
If, however - and this is what I'm suspecting - your answer is "document information, filtered by user", then {user-id} is not a resource, but just a filter for the docs resource. Which would be semantically wrong. In RESTful APIs, filtering should be done by parameters, not nested resources.
RE: WResource routing with arguments in path (for RESTful API) - Added by Roel Standaert about 6 years ago
We've done some work on this. It's still not in the master branch, though. I'm hoping to take a look at it again soon.