OperationID correction#81
Conversation
the two operationIDs where reversed. Anyway the new name "getTrafficInfluenceById" is a good one.
|
the two operationIDs where reversed so one option would have been just switching them but the new proposed operationID getTrafficInfluenceById is too good to ignore it. @ALIIQBAL786 is this fine to you? |
|
@FabrizioMoggio Thank you for the review. It's fine for me. |
Fixes: camaraproject#80 Substitutes (it is equal to) : camaraproject#81
|
I made my code modification using the github editor. It appends extra lines at the end of the file so MegaLinter blocks the merge. I'm sorry but the easiest way for me to manage this situation is to create a new PR equal to this one. So unless @ALIIQBAL786 has other means to fix this problem, being the original author of the PR, I suggest to close this PR and to create a new one. I have the new PR ready to go if we decide to go with this option. |
|
Hi @FabrizioMoggio , but now is ok, isn't it?? |
|
@FabrizioMoggio Iet me try if I can fix this issue, if not we will go with the second option. |
|
@JoseMConde Thank you for the comment, |
|
I honestly didn't noticed that, I even don't know what I did differently :-) |

What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
Corrects misleading operationId values in the Traffic Influence API spec. Changes getAllTrafficInfluences to getTrafficInfluenceById for GET /traffic-influences/{trafficInfluenceID} to reflect single resource retrieval and getTrafficInfluence to getTrafficInfluences for GET /traffic-influences to align with its plural path and list output. These changes improve API clarity and usability.
Which issue(s) this PR fixes:
Fixes #80
Special notes for reviewers:
Please verify the updated operationId values align with endpoint functionality and OpenAPI best practices.
Changelog input
Additional documentation
This section can be blank.