Мне интересно узнать, какие подходы люди использовали при создании RESTful (или квази-RESTful) API для своих веб-приложений.
Практический пример:
Допустим, у вас есть традиционное веб-приложение на основе браузера, которое использует защиту CSRF во всех формах. Скрытый ввод с токеном защиты CSRF включен в каждую форму, представленную в браузере. После отправки формы, если этот ввод не соответствует версии токена на стороне сервера, форма считается недействительной.
Теперь предположим, что вы хотите представить веб-приложение как API (возможно, используя JSON вместо HTML). Традиционно при публикации API я считал транзакции односторонними (то есть потребитель API строит запрос на основе опубликованного API вместо того, чтобы сначала запросить форму, а затем построить запрос с использованием возвращенной формы).
«Односторонний» подход ломается, когда в него входят такие факторы, как фактор защиты CSRF. Маркер защиты CSRF необходимо включать в любые сообщения POSTS / PUTS / DELETES, отправляемые потребителем API.
Я пытался придумать, как лучше решить эту проблему. Запрос формы каждый раз, когда требуется выполнить вызов API, кажется очень неловким (особенно при работе с асинхронными операциями), но все другие альтернативы, о которых я думал, по-моему, побеждают защиту CSRF (или, по крайней мере, пробивают дыры в ней) ), что недопустимо.
Кто-нибудь из вас имеет представление об этом?
Спасибо.
(Не то чтобы это должно было иметь большое значение, поскольку проблема концептуальна и не зависит от платформы, но я имею дело с традиционным стеком LAMP и использую Symfony 1.4 в качестве моей прикладной среды. Моя цель - опубликовать веб-сайт в формате JSON API, позволяющий разработчикам создавать мобильные / настольные приложения, которые будут хорошо играть с существующим веб-приложением.)