Personally, I deal with such validations within the business logic layer, as described in the article.

That way, it is enforced however the request has come in.

In my current app for example, here's how it goes:

-> Request -> REST Layer -> Command dispatched -> Command handled by a command handler in the business layer.

Command handlers are the ones responsible for enforcing business rules. With your example in mind, the command handler would be the one fetching the existing entity and would throw an exception if it could not be found. That exception would in turn be handled by a global exception handler/filter, which would convert it appropriately (e.g., as a 404 response with no content for an update request targeting an unexistent entity).

What I'm describing here is the CQRS pattern (Command Query Responsibility Segregation), which I like a lot as it helps keeping things clean/clearly separate.

Whether you use CQRS or not doesn't matter all that much though; your rest layer could also simply call a method on a service, that would throw an exception in the same way, leading to the same result. CQRS has major advantages, but that's another story ;-)