Skip to content

Swagger Look Messy with Subresource #1316

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

Closed
bitcoinporn opened this issue Aug 14, 2017 · 12 comments
Closed

Swagger Look Messy with Subresource #1316

bitcoinporn opened this issue Aug 14, 2017 · 12 comments

Comments

@bitcoinporn
Copy link

bitcoinporn commented Aug 14, 2017

I working with sub resources, and now swagger page look very messy.

Subresource should not appear on target groups. Any setting to prevent this?

screen shot 2017-08-14 at 8 39 41 am

@soyuka
Copy link
Member

soyuka commented Aug 14, 2017

Looks fine 😆

@bitcoinporn
Copy link
Author

also consider to add depth settings.
I found we can have same naming on sub resource

@soyuka
Copy link
Member

soyuka commented Aug 16, 2017

I'd like a case reproduction for name collision if you have one!

@bitcoinporn
Copy link
Author

sorry typo...
i mean we can't have same sub resource name.
example:
i have 2 entities, that 2 entities have "likes" sub resources.
/contents/{id}/likes
/events/{id/likes

when i want to make both as "user" sub resources, its not allowed.
/users/{id}/events/{id}/likes
/users/{id}/contents/{id}/likes

we should allow this practices.

@bitcoinporn
Copy link
Author

@soyuka : do you have suggestion for quick fix for this?

@soyuka
Copy link
Member

soyuka commented Sep 1, 2017

@synchr0n123r this look like a bug, I need to take a closer look.

soyuka pushed a commit to soyuka/core that referenced this issue Sep 1, 2017
@soyuka
Copy link
Member

soyuka commented Sep 1, 2017

@synchr0n123r I don't get it, this should be good. All you have to do is add a Subresource on Events and Contents in the User entity.

See the referenced commit, that's exactly what the test is trying to do and I'm getting the correct results.

Please give me a reproduction case in a gist if you can.

@soyuka
Copy link
Member

soyuka commented Oct 24, 2017

Any updates?

@Nightbr
Copy link
Contributor

Nightbr commented Nov 22, 2017

Hey same issue here, I think it should be nice to control the depth of subresources.

For example, If I have /api/publications/{id}/comments and /api/users/{id}/publications, I don't want to generate the route /api/users/{id}/publications/{publications}/likes.

I tried by adding @MaxDepth(1) annotation but no effect (I'm pretty sure it's because MaxDepth is related to the serializer and not the route generator but I give it a try ^^)

Thanks!

@soyuka
Copy link
Member

soyuka commented Nov 22, 2017

I tried by adding @maxdepth(1) annotation but no effect (I'm pretty sure it's because MaxDepth is related to the serializer and not the route generator but I give it a try ^^)

No you're right. Should be pretty easy to implement in

private function computeSubresourceOperations(string $resourceClass, array &$tree, string $rootResourceClass = null, array $parentOperation = null, array $visited = [])

Feel free to PR on this :).

@Nightbr
Copy link
Contributor

Nightbr commented Nov 22, 2017

@soyuka sure I am on it with also a bug with normalization_context with subresources:
api-platform/api-platform#440

This was referenced Nov 23, 2017
@Nightbr
Copy link
Contributor

Nightbr commented Mar 5, 2018

I think we should close this with the PR merged!

@soyuka soyuka closed this as completed Mar 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants