Можно конечно создать прослойку на клиенте и прослойку на сервере, которые будут собирать и разбирать REST, но зачем? Почему я должен думать о том как данные передаются в приложении. Я что писатель протокола http? Я же не Рой Филдинг для которого возможно это было важно, мне вообще до лампочки как передаются данные, лишь бы доходили в целости. Я хочу думать о абстракции, о масштабируемости, о архитектуре, а не накладывать искусственные ограничения, а потом трахать себе ими мозг.

POST более чем достаточно. melky, Придумаешь где не достаточно, напиши.

Gozar, прочитай мой посты выше :)

POST - это способ отправки данных, а REST - это паттерн, т.е. кислое и длинное

Хз, Backbone использует REST и в нем все делится POST, GET, PUT, DELETE. Свое представление о REST я основывал на Backbone представлении. Если я не прав, ну что ж бывает.

ага, прочел, лень править пост :)

Ну дык реализаций множество. Я например использую передачу JSON и юзаю GET для получения данных, а POST для изменения.

Главный постулат REST, что нет передачи состояния и мы оперируем простым и очевидным протоколом для работы, при этом сервер ничего не знает про клиента и наоборот. А какой протокол мы используем и какой транспорт - это уже на наше усмотрение.

Что это значит? что такое состояние?

Ну имеется ввиду, что нет значения откуда был послан запрос и состояние того, кто посылал, т.е. например если мы соединимся по сокету с сервером, то сервер будет иметь этот объект "сессии" и может как-то выделять запросы конкретных клиентов.

В REST же мы тупо передаём данные и на основе переданных данных уже работаем.

ЗЫ: вот яркий пример НЕ REST - SOAP

А можно яркий пример при построении SPA? А то этот яркий пример как абстрактный конь. :)

Про состояния я не понимаю. База должна синхронизироваться с клиентом и ясен пень она ничего не знает о клиенте, да и собственно о сервере она тоже ничего не знает. Запросы к ней прилетают через прослойку(php). php тоже ничего не знает о клиенте. да и клиент о php.

А причём тут SPA? :) Может я вопрос не понял, поясни.

Ты посылаешь простой запрос, чтобы сказать, что например юзер авторизован, то шлётся аторизационная кука или ещё что: запрос обработался, вернулся результат и всё закончилось. Этот запрос может обработать любой сервер из кластера, т.к. нет никакой привязки и такую схему легко масштабировать.

Когда ты соединяешься, например, по WebSokets, то клиент связан с вполне конкретной удалённой машинкой и эту информацию можно использовать в логике приложения (т.е. ты можешь например взять и отправить клиенту сообщение) и следовательно сложнее масштабировать, т.к. нужен дополнительно синхронизирующий кластер.

***

Синхронизация БД - это вообще из другой песни.

Ответил выше.

Хз уже как разжевать, вот абстрактный пример:

REST

Привет Сервер, дай картинку! - ОК, держи - Пока!

не REST (причём с передачей состояния)

Привет сервер, дай картинку! - Ок, держи ...

Слушай клиент, тут тебе письмо пришло и вот, зацени эту милую картинку с котиками -
О спасибо сервер, продолжай держать меня в курсе...

kobezzza,
Спасибо дошло, чат(кот.держит соединение) - не REST. Теперь до меня дошло, что backbone еще большее говно, которое лезет туда, куда его не просили. И все эти их высокопарные слова про REST бессмысленный набор слов.

Ну или надо сразу брать готовую серверную часть для работы с backbone, писать свою мне не понравилось на основе их методологии.