Ну, это как реализуешь :) Если обновляющийся ифрейм или интервайльный аякс, которых дёргает какойнить getMessages, то REST :)

***

Посмотри Meteor, там используется специальный протокол, который позволяет удалённо выполнять JS функции на сервере, это полная противоположность REST.

Да я понял, поправил в мессаге выше. Спасибо, что разжевал, а то бы так и думал что рест это put,get,post,delete :)

ну я и оффтопер :haha:

поэтому ты пишешь свой фреймворк ? :)

пока не приходилось, но интересно послушать про такие штуки. скоро буду их разрабатывать


на NodeJS - я разницы не увидел

я даже не стал его изучать, когда он вышел. не понравился :)
а теперь, правда, догонять приходится

а могло бы быть так:

просто смотрится лучше :) KISS ...

... если я вообще правильно понял, что такое REST

хорошо сказано!

нагуглил Gist: https://gist.github.com/nachiket-p/2964422
неплохо. отличный старт для приложух, но не представляю, сколько потребуется времени на изучение всего этого дела (я про Derby, Meteor...)

Потому что на момент начала работы не было ни одного каркаса который был бы создан для SPA, сейчас я не сёрфил проекты, но на 90% уверен, что их по прежнему нет, хотя для меня уже это не важно.

Я уже писал выше, что вариант возможен, но мне так думать неудобно. У себя я сначала определяю, к кому я обращаюсь, а затем что я делаю.

В моем случае один блок = один файл. Все в одном месте то, что касается этого блока. Выкинул файл, нет блока. А в другом случае, мне что нужно лазить по файлам get, put, delete - выискивать там то, что относиться к блоку?

Я понимаю, что эти два варианта жизнеспособны, но мне сложно думать, что я иду, а затем думать куда иду. Поэтому лучшим вариантом наверное будет брать готовую серверную часть, которую проработали.

Вот сам и не усложняй! У меня один POST, а у тебя 4 вида метода ломания мозга: PUT, DELETE, GET, POST.

http://habrahabr.ru/post/38730/
Вот каким местом очевидно, что POST это изменить? Тогда уж нужно вводить CHANGE и понеслась ...

Таким образом мы скатываемся от абстрагирования к низкоуровневым протоколам. Зачем?

В чем очевидный плюс? Я вижу минус - искусственное ограничение с неизвестной причиной. Почему взяли 4 типа, почему не 24, не 2, не 100500? Зачем об этом вообще думать?

Что делать, когда нужно сделать PUT + CHANGE + GET? На это тоже нужно правило придумывать? PUG или PUCH например :)

а я использую подход, когда тип операции является названием файла, а для отправки данных только GET и POST

getUser?...
deleteUser?...

:)

При этом физически файл может и не существовать, т.е. вместо action=getUser просто getUser.

ЗЫ: все предложенные варианты являются REST :)

Я раньше тоже использовал GET, оказалось без него проще. Проще о протоколе не думать.

POST позволяет и GET и POST, а вот GET это просто урезанный POST, хотя по сути одинаковы. Если нет веской причины использования того или иного протокола(оптимизация, архитектура ...) зачем заморачиваться?

Gozar, мне казалось это очевидно: get позволяет делать ссылки, т.к. данные передаются через URL :)

Наверное и правила какие-нибудь придуманы, где кошернее GET, а где POST? :)

Но по сути POST приходиться, а GET это типа когда "правильнее" :D

Конечно, данные для получения GET, данные для изменения POST. Да и проблемы я не вижу в этом :)

Да и я не вижу проблемы в том, чтобы использовать POST, вместо искусственно добавленного GET, где он не нужен.

Пруф или не было :)

С точки зрения пользователя современный SPA (т.е. с использованием history API) ничем не отличается от простого сайта. Т.е. там также меняются урлы, загружаются странички и т.д.

Смысл в том, чтобы встать над протоколом, а не придумывать хитрые правила, смысл которых не очевиден.

Небыло, Я подумал ты про другое, поэтому и написал ... т.к. не понятно при чем тут GET и хистори?

Пользователь вводит в поле поиска инфы строку, происходит поиск, затем найденный результат кидает как ссылку другому пользователю с фразой "забанили в гугле?" :)

И ему глубоко по барабану, что реального "релоуда" страницы не было. Кстати что гугл, что яндекс работают именно так :)

Это как-то объясняет зачем ты используешь GET для отправки данных? ;)
Я не понял.

kobezzza,
Я пытаюсь понять зачем использовать два протокола, когда достаточно одного? В чем необходимость? Почему не 3, 10, 100500?

Кажись понял к чему ты ведёшь, мол зачем при отправке ставить тип?

Но дело в том, что я этого не делаю, я пишу просто ajax({ ... }), а фреймворк сам решает как и что отправить, и в случае если изменился URL, то он будет иметь ввиду GET, но ещё более вероятно, что он для транспорта использует WebSocket, т.к. у меня используется адаптор WebSoket который предоставляет интерфейс XMLHttpRequest.

Да. Верно. Нет необходимости, нефиг и юзать. Именно эта часть вынесла мне мозг в Backbone.

Ждем реакцию melky.

А как они должны дружить? Бери да используй. :)

то бишь вот так
а не так
?

второй вариант даже можно прочитать как "положить (put) заказ (order) на имя (name) Юля (julia)"

потому что у CRUD всего 4 операции - Create, Read, Update, Delete. и соотв. методы HTTP получаются: PUT, GET, POST, DELETE. это выглядит просто?

то бишь их всего 4. ни больше ни меньше. о всяких HEAD, и других я не хочу думать... как будто их нет вовсе :)

"не знаю, не использовал". если там нельзя менять способ отправки данных, то это ... это плохо :) У PHP насчёт метода PUT свои приколы, например.

это просто говорит о том, что, возможно, искомый инструмент не подходит для решения задачи.

melky,
объедини операции, не можешь? на этом все, надоело расписывать очевидные вещи. Зачем вставлять себе палки в колеса ради какой-то неясной идеи мне не понятно.

Почему POST это UPDATE? Почему нет UPDATE? Почему я должен ограничиваться только 4 методами? Это искусственное никому не нужное ограничение. По сути бред.

В идеале я не должен думать о протоколе совсем, ни минуты. Это не мое дело как оно там внутри передается, так же как не должен думать о том какие провода куда подключены и что там за материнская плата на промежуточном сервере.

слишком хитрожопый и лезет туда куда лезть не должен! Либо тогда уж предоставляй и серверную часть.

Пофиг, он слишком монструозный, чтобы о нем думать. Там не только эти ограничения. Там ограничений еще есть. И решаются также через монструозные костыли, которые ломают всю светлую идею. Идея гуд - реализация щит.

REST полная шляпа ИМХО.

Round 2. Fight!

:D

http(s)://domain/api/v1/method

Пример запроса:

https://e.mail.ru/api/v1/collectors/add?

collect = [
   {
      email        : 'test@mail.ru'
      type          : 'ftp',
      password  : '******'
   }
]

Пример ответа:

{
   "body" : [
      {
         "type" : {
              "error":  "invalid",
               "value": "ftp"
          }
      }
   ],
   "email" : "test@corp.mail.ru",
   "status" : 400,
   "htmlencoded" : true
}

Всё с тобой понятно, вместо того чтобы сказать "спасибо", ты опять начинаешь "а я знал, а ты не сказал ключевое слово Angular...". Делай как считаешь нужным.

Спасибо!

Не за макси-са, от себя.