And as you say, since certain aspects of the API (like honk horn) are unfit for REST, does it make sense to have the other parts of the API in REST? And then you've have two API's at once?
Then you need to have another resource that encompasses the aspects that need to be changed. Sometimes resources have to be somewhat abstract.
> since certain aspects of the API (like honk horn) are unfit for REST, does it make sense to have the other parts of the API in REST?
If the application benefits from the constraints that REST provides then why wouldn't it make sense? It's still one API, "honk" and "flash" don't need to be walled off from the other elements of the API in any way.