Ок
Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.
Речь же про API, когда это пользователи начали лезьть в потроха сервиса.
-- Сохранение состояния страницы через HTML5 History API (как бонус)
Опять же, очень косвенное отношение к REST API
-- Нет путаницы с дополнительной передачей параметров в запросах и обработкой их на сервере
Как раз и начинается путаница. Что передаем через GET параметры, что-то через POST в один и тот же обработчик.
-- Прозрачная логика клиентской части приложения
-- В случае надобности легко предоставить RESTful API для сторонних приложений
А другие протоколы не предоставляют этой возможности?
У REST есть много неопределенностей и из-за этого у каждого появляются свои реализации, которые они считают эталонными.
Нет более менее четкой спецификации. Например ответ о ошибке:
1. HTTP код
2. Всегда 200, информация об ошибке в ответе
3. 1 и 2 вариант
Формат ответа. Допустим вызываем метод получения пользователей:
1. [{ login: '' }]
2. { data: [{ login: '' }] }
3. { data: [ 'users': { login: '' }] }
Кто-как любит, так и делает. Большой минус если приходится интегрироваться с несколькими сервисами.
Веселье начинается, когда потребности выходят за рамки простого добавления, получения списка, удаления (типичный CRUD), т.е выходим за рамки /:collection/:id
Вот есть какая-либо сущьность, у который есть свойства и методы. Как эти действия выполнить?
1. POST /:collection/:id/on
2. Передавать "действие" в теле POST
3. Или вообще использовать, PUT, PATCH
Небольшая проблема возникает, когда идет кроссбраузерный запрос (CORS) к нашему API. На каждый url (/:collection/:id) будет слать предварительный OPTIONS запрос, дополнительные задержки.
Добавили GET/PATCH/DELETE обработчик /:collection/:id. И хотим в браузерном приложении использвать JSONP, чтобы избавиться от политик CORS. Придется добавлять еще один обработчик (3-в-1), для поддержки JSONP (он ведь только GET).
Нет стандратых инструментов для описания сервиса, по типу WSDL. Точнее более-менее широкоиспользуемых.
При типичном REST API, документация и параметры описываются вручную. Документация будет постоянно отставать.