Some API endpoints can take both path and query parameters. (Path parameters can be thought of as "equals" criteria and query parameters as filtering criteria.) Including the separators for both kinds of parameter together with no path parameter between them (e.g. "/?") is confusing and should not be done.
Explanation:.
A path parameter follows immediately after the resource it refers to separated by a forward slash ("/"). For example, in "https://gateway.api.berkeley.edu/hr/v3/employees/10146454" "employees" is the resource and "10146454" is the employee-id path parameter. A GET request to that URL should return a list of employee records that have an employee-id equal to "10146454" (hopefully, just one!).
A query parameter (or a list of them) follows after the entire endpoint separated from it by a question mark ("?") and from each other by ampersands ("&"). For example, in "https://gateway.api.berkeley.edu/hr/v3/employees?change-from=2022-08-24&change-to=2022-08-24" "change-from" and "change-to" are query parameters. A GET request to this URL should return a list of employee records that were changed on August 24.
Since the this API takes both, you might inadvertantly include the slash that usually precedes the path parameter when you're only using query parameters–for example, "https://gateway.api.berkeley.edu/hr/v3/employees/?change-from=2022-08-24&change-to=2022-08-24." While there's no established rule about what a request to that URL should return, it's Berkeley's convention to consider it incorrect usage and return a "400 Bad Request" error. On the deprecated gateway, however, that request works as though the slash weren't there and returns the expected list.
When the new gateway was released, it was returning "403 Forbidden" errors for such requests due to a misconfiguration. We thought about fixing it so it'd return 400s, but In order to uphold the principle of least change for our clients, we've since configured the gateway to accept the extra slash just like the old one.
In the near future, we'll go through and clean up all of these inconsistencies that had been introduced in the old gateway. We'll of course communicate such changes well ahead of time so you can reflect them in your code.