Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Would be nice to allow multiple identifiers for a route #23

Open
weierophinney opened this issue Dec 31, 2019 · 3 comments
Open

Would be nice to allow multiple identifiers for a route #23

weierophinney opened this issue Dec 31, 2019 · 3 comments

Comments

@weierophinney
Copy link
Contributor

I think this would be a useful feature but I'm also open to feedback on how I might be doing it wrong or should be doing something differently. I have a route which includes 3 identifiers. My route essentially looks like

/api/apiname/resource/:resourceId[/subtype1/:subtype1/subtype2/:subtype2]

I don't really want to make another resource which was just resource id and subtype 1, and I don't think putting in 2 optional parts in the route is a good way to go. It doesn't appear that I can set any more than a single string as the identifier. In the example above, the HAL links for the entity won't include both subtype1 and subtype2, but does contain up to :resourceId.

If route identifier were allowed to be an array, it seems that the above would be possible, but considering the number of places that this touches, I wanted to get some feedback on it before going forward with a change or PR.

To me, it seems this could be a good idea and I don't see a problem with being able to support it, but would appreciate feedback.


Originally posted by @dstockto at zfcampus/zf-hal#36

@weierophinney
Copy link
Contributor Author

You can do this with RPC calls. See https://github.com/zfcampus/zf-apigility-doctrine/blob/master/src/Server/Controller/RpcController.php for a working example of
/resource/resource_id/field/field_id

Anything deeper than one should be referenced as

/field_resource/field_resource_id


Originally posted by @TomHAnderson at zfcampus/zf-hal#36 (comment)

@weierophinney
Copy link
Contributor Author

@dstockto Have you given it a try yet? One other possibility is to use a combination identifier, and split it in your resource. As an example, your route would be /api/apiname/resource[/:resourceId], but the contents of :resourceId would be something like abc-123. Your resource class would then split this into abc and 123, allowing you to get the different keys. This has the added benefit that it would continue to work with the current code.


Originally posted by @weierophinney at zfcampus/zf-hal#36 (comment)

@weierophinney
Copy link
Contributor Author

Apigility Doctrine supports multi-key splitting by default using the '.' separator, therefore supporting a route like this: /orderdetails/num.code.
The DoctrineResource is able to query properly the DB, constructing the entity properly, the problem though is the HAL rendering.
If I configure the 'metadata_map' for the resource with 'entity_identifier_name=num' the rendering is done properly but the links it builds are missing the second param (i.e. /orderdetails/num); if I put 'entity_identifier_name=num.code' the request returns the error "Unable to determine entity identifier for object of type "Entity\Orderdetails"; no fields matching 'num.code'".

Of course a very simple callback on event 'renderEntity' pushing the composed key in the 'self' link solves the problem (literally 5 lines of code).

It would be nice though to have the functionality available out of the box from the service configuration.


Originally posted by @MassiAtZend at zfcampus/zf-hal#36 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant