> But what about if it was necessary to have one command that changed the state of more than one resource? Then you need to have another resource that encompas

> But what about if it was necessary to have one command that changed the state of more than one resource? 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.