fix: uri template should respect rfc 6570

[soyuka]

Q	A
Branch?	3.0 as a bug fix?
Tickets	na
License	MIT
Doc PR

Currently we have .{_format} in our URI template which is not valid according to RFC 5670. We should use {._format}.

It breaks operation names how to solve this? Should api-platform generated operation names be concerned by the backward compatibility ? Maybe document that if a user is using an operation name somewhere he should specify the name inside the metadata?

[stephanvierkant]

Isn't this a breaking change? I'm using .{_format} in my application and 3.0.3 breaks my application.

[burned42]

Same here. It worked on 3.0.2 with the URI templates generated by the upgrade command and 3.0.3 now breaks my application, too.

Replacing .{_format} with {._format} in all the URI templates fixes the issues after upgrading to 3.0.3.

[dannyvw]

After installing 3.0.3 our application triggers the php max execution time on this line https://github.com/phpDocumentor/TypeResolver/blob/1.x/src/Types/ContextFactory.php#L189 but not sure if this library has something to do with this PR.

3.0.2 has no issues.

[silverbackdan]

I'm not sure if this commit caused the issue or another somewhere. My application was working on the dev branch fine until 3.0.3 released, then I had to change my uri templates to match.

Eg.

- $newOperation = (new HttpOperation(HttpOperation::METHOD_GET, '/me.{_format}'))
+ $newOperation = (new HttpOperation(HttpOperation::METHOD_GET, '/me{._format}'))

Or XML operation definition:

<operation class="ApiPlatform\Metadata\Patch"
                       name="submit_patch"
                       method="PATCH"
                       - uriTemplate="/forms/{id}/submit.{_format}"
                       + uriTemplate="/forms/{id}/submit{._format}"
                       read="true"
                       deserialize="false"
                       validate="false"

Or I got a 404 not found.

But working on dev until the day of 3.0.3 release or near to it, even after this one was merged, seemed to work fine and tests passed in my application.

[soyuka]

@dannyvw I don't get it why should this be related?
@everyone else can you explain to me how this breaks? In Symfony routing this should not have any impact I thought I covered the backward compatibility layer here.

[dannyvw]

@soyuka Not sure either, but it does something with { and } and it looks like it crashes in some loop. The phpdocumentor library is used as dependency inside Symfony. Will check it later.

[maxhelias]

@dannyvw A max execution time can stop anywhere without being the consequence of this stop. If you have less resources available it will stop early and if you have more it will stop later.
You should rather profile with a tool, like Blackfire or other, your request to know what takes so much time.

[burned42]

@soyuka For me the upgrade command converted former Subresource annotations to ApiResource attributes with custom URI templates which included .{_format}. With 3.0.3 those endpoints now just return empty collections and the swagger ui shows _format as a required parameter (but doesn't include it in the request when trying via swagger ui, so it seems to be just some displaying issue maybe).

So e.g. the same GET request to a collection endpoint returns a collection with the correct items with {._format} but does return an empty collection with .{_format} in the URI template.

As said, it's easily fixed by just moving the . one to the right, but I guess it's still a BC break.

edit: to make this clear, there are no error messages or similar, the requests get processed just fine, they just don't produce the expected result anymore.

[dannyvw]

@maxhelias I know, but it is only triggered with the 3.0.3 release and always on the same file/line. It is triggered by the metadata system. So maybe it has something to do with this PR. I will check it later, but maybe someone has the same issue. So it was more as information.

[soyuka]

I'm fixing this thanks for the report and sorry about this breaking change