Você pode usar cookies para manter o estado do cliente, porque eles são um mecanismo de armazenamento do lado do cliente. Você pode usar outros mecanismos de armazenamento do lado do cliente, por exemplo, websql ou localstorage.
O único problema com os cookies, os cookies de sessão estão violando a restrição de apatridia. Então, a menos que você use cookies de sessão, você está bem. Você deve se perguntar o que aconteceria quando o servidor fosse reinicializado. No caso de cookies de sessão, sua sessão será perdida. No caso de cookies normais, nada relevante acontece, seus pedidos serão respondidos da mesma forma como antes.
Eu acho que quando o servidor escreve os cookies que é uma coisa de zona cinza, especialmente se estamos falando de cookies somente HTTP (que não são acessíveis no javascript do navegador). Nesse caso, o serviço altera diretamente o estado do cliente. Poderíamos argumentar que os cabeçalhos dos cookies são parte da representação, mas isso é uma meia verdade, eu acho. Se sua API REST tiver um domínio diferente do seu cliente, defina os cookies somente no domínio do cliente e acesse seu conteúdo, por exemplo, com o javascript do lado do cliente, se estivermos falando sobre navegadores.
Não sei se o armazenamento em cache e os cookies estão em conflito uns com os outros. Não me lembro de tal problema.
Você deve usar o cabeçalho Authorization em vez de cookie, mas acho que não é uma tragédia se você definir o nome de usuário e a senha em um cabeçalho somente HTTP. Ou você define um cookie persistente com algum hash (se estiver registrado no servidor como um recurso por um longo tempo). Eu acho que ainda é mais seguro do que armazenar esses dados, por exemplo, no localstorage.