In terms of REST, especially if you apply the HATEOAS principle, it really doesn't care how you name your URL. The client should not really care about the URLs, as the server should generate the links for the client.
There are a few guidelines though, good REST URIs should be a noun, not a verb. URIs should address objects, rather than addressing methods.
REST API should have a limited number of general purpose verbs. Good HTTP REST API should use HTTP verbs correctly, for example use GET request for retrieval request and POST/PUT for data modification/creation request.
Some example of good REST URLs (either one to use is a matter of taste):
GET /employees/{employee_id}/vacations
GET /employees/{employee_id}?details=name,vacations
to obtains the list of vacations and vacation requests related to the employee with a given employee_id.
I think vacation requests should simply be vacations with status=pending, however if you decide that you want to expose vacation requests as separate resource, REST doesn't really prevent you from doing that either. As long as the server produces the URLs per HATEOAS, ultimately it doesn't really matter if it's exposed as separate URL.
As per HATEOAS, vacation list resources should contain a link (and form) to create vacation request, which may look like this:
POST /employees/{employee_id}/vacations
and a list of URLs that can be used to retrieve and update details about a vacation, which may look like this:
GET /vacation/{vacation_id} (for retrieving detail)
PUT /vacation/{vacation_id} (for updating detail)
PATCH /vacation/{vacation_id} (alternative for updating detail)
(important: update requests must be conditional request/If-Match to protect against concurrent update)
Non manager employees can only update pending vacation, if they attempt to update approved vacation, the vacation status should revert back to pending. Non-manager cannot modify the status field directly otherwise.
The manager that's responsible for approving the vacation of an employee have permission to set their vacation status to approved or rejected.
An employee can retract their vacation request by sending DELETE request:
DELETE /vacation/{vacation_id}
which would set the vacation status to retracted.
Note how all requests related to the same object are done against the same URL, but with different HTTP methods. This gives the client the context that these request all revolves around the same object. They can use this for example, to implement caching, to automatically invalidate the data cached for the same URL when making a POST/PUT/DELETE request to that URL.
vacation/vacationsin almost all of your identifiers? What's the duplication for?GET /vacation/vacations/, which vacations would be returned, only his own or all that he has the right to know about? Would that change if the employee got the "vacation approval" rights?