Me interesa saber qué enfoques han adoptado las personas al crear una API RESTful (o cuasi-RESTful) para sus aplicaciones web.

Un ejemplo práctico:

Supongamos que tiene una aplicación web tradicional basada en navegador que utiliza protección CSRF en todos los formularios. Se incluye una entrada oculta con un token de protección CSRF en cada formulario presentado en el navegador. Al enviar el formulario, si esta entrada no coincide con la versión del token del lado del servidor, el formulario se considera inválido.

Ahora supongamos que desea exponer la aplicación web como una API (quizás utilizando JSON en lugar de HTML). Tradicionalmente, al publicar una API, he considerado que las transacciones son unilaterales (lo que significa que el consumidor de API crea la solicitud en función de la API publicada en lugar de solicitar primero un formulario y luego crear una solicitud utilizando el formulario devuelto).

El enfoque "unilateral" se rompe cuando entran en juego cosas como el factor de protección CSRF. El token de protección CSRF debe incluirse en cualquier POSTS / PUTS / DELETES enviado por el consumidor API.

He estado tratando de pensar en la mejor manera de abordar esto. Solicitar un formulario cada vez que se debe realizar una llamada a la API parece muy incómodo (especialmente cuando se trata de operaciones asincrónicas), pero todas las otras alternativas que he pensado por mi cuenta parecen derrotar la protección CSRF (o al menos perforarla) ), lo cual es inaceptable.

¿Alguno de ustedes tiene una idea de esto?

Gracias.

(No es que deba importar demasiado, ya que el problema es conceptual y agnóstico a la plataforma, pero estoy tratando con una pila LAMP tradicional y uso Symfony 1.4 como mi marco de aplicación. Mi objetivo es publicar una API web en formato JSON que permita a los desarrolladores para hacer aplicaciones móviles / de escritorio que funcionen bien con una aplicación web existente).