NelmioApiDocBundle
NelmioApiDocBundle copied to clipboard
nelmio
Symfony form in GET-request
would that mean a GET request with a body? this is very unusual, and some proxies might discard the body. afaik elasticsearch used to do it, but they switched to POST meanwhile because GET with body was creating problems with tools not expecting it.
Without body.
Let's say I have a form FilterType with two fields ("name" and "surname") and block prefix "filter". In NelmioApiDocBundle v2 I used this form in "input":
input = "ApiBundle\Form\Type\FilterType"
In the sandbox I made the following request:
/api/v1/users?filter[name]=Michael&filter[surname]=Phelps
How can I do the same in the third version?
That's not supported in 3.x unfortunately, mostly due to the way parameters are implemented in swagger. That could be added but the biggest challenge is to find a nice syntax.
Maybe we need to rethink @Model to cover all cases more nicely. What do you think about extending all zircote/swagger-php annotations in the bundle and add a model field to the annotations needing it instead of having @Model ? That would allow us to provide features more integrated with zircote/swagger-php annotations...
could it be possible to add a model field to zircote/swagger-php instead? that might be more straightforward and less confusing. but is only possible if the model field would make sense for zircote itself as well - but from how i understand things, it would make sense.
Thinking about it again we could also use the ref field:
/**
* @Response(response=200,
* @Schema(ref=@Model(type=""))
* )
*/
when it is not clear what @Model should be used for. That makes things much clearer imo.
could it be possible to add a model field to zircote/swagger-php instead? that might be more straightforward and less confusing. but is only possible if the model field would make sense for zircote itself as well - but from how i understand things, it would make sense.
Well they use ref a lot, I don't think this would be accepted. Plus we would have no way to pass options as well (serialization groups for instance).
We have the same problem. We use Symfony Forms in GET requests for filtering content. That would be nice feature!
I have faced with the same issue during describing JSON:API endpoints.
For pagination I'm using query page[number] and page[size] parameters names. Instead of FormType I have described page as following structure:
class PaginationParams
{
public $number;
public $size;
}
It would be great to have a possibility to add a reference to such models to describe query parameters. Currently, the only way how to do this is to copy-paste query parameters annotations in each controller action.
BTW OpenAPI 3.0 supports specific serialization format deepObject which provides a possibility to describe query parameter array keys with square brackets.
