А вот и нет. DELETE — это тоже изменить ресурс, а не удалить ресурс, т.е. его можно рассматривать как EDIT с точки зрения идеологии REST. Т.е. запрос всё равно один.
Если следовать вашей логике, то и добавлять нужно методом PUT, что не верно.
Такого мы не реализовывали, но я полагаю — отправлять методом POST в той же структуре (отдельные блоки для добавленных, удаленных и измененных) по адресам таблиц (URL/synchservice/tablename). Т.е. GET — вы берёте таблицу, POST — добавляете данные в таблицу.
Если нужно еще и создавать таблицы, то это PUT, если удалять — DELETE.
Также не забудьте про корректную обработку ошибок транзакций, как если базу сразу начнут редактировать несколько клиентов плюс ещё сам сервер в придачу.
Только как в SVN — перед тем, как добавить, желательно для начала обновить
Судя по комментариям, не у одного автора — очень много людей в коментариях даже не заметили подвохов и нестыковок с жизнью и физикой. А ведь это хабр, где подавляющее большинство — технари, а значит хоть два курса, но изучали физику в институте!
Не совсем понял вопрос, но местоположение девайса обычно определяется на клиентской стороне по GPS, а затем уже отправляется на сервер. Сервер же по токену будет знать, какой из девайсов к нему обращается.
Отличный вопрос, мы как раз реализовывали подобное с использованием REST. URL/synchservice/ — возвращает текущую версию базы в формате, например, секунд прошедших с 1970 года; URL/synchservice/tablename — возвращает полную таблицу так, как она есть в базе; URL/synchservice/tablename/<current_version_on_client> — возвращает только изменения, произошедшие в таблице от момента current_version_on_client до текущей версии базы.
Этих методов должно хватить. В самом XML или JSON, который будете сериализовать, необходимо завести три секции — одну для записей, которые нужно вставить, вторую — удалить, третью — обновить. Это самый неизбыточный способ, по крайней мере это реально работает уже 2 года в довольно большой энтерпрайз-проекте.
Данные на стороне клиента желательно парсить SAX-парсером, т.к. дамп базы при первой синхронизации может быть достаточно большим. На сервер-сайде к каждой таблице нужно хранить таблицу истории со след. параметрами:
1. Операция (D — delete, I — insert, U — update)
2. Время операции.
3. ID записи в основной таблице.
Полностью согласен насчёт REST, я сам его большой поклонник. Объекты описать — не самое сложное занятие, но все же я люблю автоматизировать всю ручную монотонную работу там, где это можно. Так голова останется только для решения действительно важных задач.
Ну и API тоже не всегда простое — теперь бывают и очень сложные клиенты. На одном моем проекте было, например, более ста различных веб-сервисов с множеством параметров. В таких случаях автоматическая генерация очень помогает.
Пусть я могу быть и не согласен с вами, но очень уважаю вашу смелость. Поэтому плюсанул в карму, а не пост. Хорошо, что есть ещё люди, которые не боятся высказывать своё мнение!
У меня такое ощущение, что вы не совсем понимаете ту же квантовую механику. Словами оперируете, но понятия подменяете. На макроуровне будут действовать законы макроуровня, и то что галактика нас больше, скажем, во столько же раз во сколько мы больше кварков, не делает нас «релятивистскими частицами» относительно Галактики.
То же самое и с вашей статьёй — аналогии интересны, но всё, 90%, высосано из пальца. Возьмём ту же цикличность времени — вы почему-то возводите её в свойство времени, но это же абсолютный бред. Обращение планет вокруг звёзд (как и электронов вокруг ядра) ну вообще никак не зависит от свойств времени, это просто ещё один вид движения, описываемый вектором силы притяжения и центробежной силы.
Время относительно неподвижной частицы строго линейно, без всяких циклов. Относительно наблюдателя движущихся частиц — может замедляться, но до какого-то предела. Обратно не пойдёт, хотя бы потому что корень в формуле всегда положительный. Какой тут нафиг цикл?
Если вы имеете в виду NN — всё было быстро, но Netscape 6 был сущим адом. Он даже простейшие страницы образца 2000 года отображал медленнее, чем IE5.5 раз в 5. Так что и тогда уже были говнокодеры :)
Совершенно согласен! Раздражают очень люди, которые думают, что с количеством технологий становятся лучшими программистами. С другой стороны, люди которые не считают себя гениями или эрудитами работают лучше.
Зато вы научитесь превосходно делать дерьмо, намного лучше чем те кто делает мёд. А кто знает, может в вашей задаче вам нужно 100 кг дерьма а не ложка мёда?
Тут тоже можно разделить большие компании на 2.
1. Продуктовые, либо работающие с 1-2 крупными заказчиками. Там как нечего делать вылетит 60 человек в день.
2. Сервисные, с диверсифицированными заказами. Там намного стабильнее, но… и намного больше геморроя для кого-то.
У нас клиент очень просил с сервером общаться только через HTTPs. Хотя секьюрных данных там не было совсем, и воровать ничего не имело смысла, но конечно сделали — американцы если видят в углу адресной строки красивую иконку, сразу же расслабляются. Также в дебаг-версии одно время пароли хранились в незашифрованном виде (требование заказчика) — при всех SSL, уровнях защиты и конспирации, пароли юзеров на 95% были 123456, qweqwe, 19John58, <название нашего продукта> и т.п.
Так что я добавил бы к списку автора ещё и «те люди, которые на PayPal аккаунт ставят пароли „paypal“».
Если следовать вашей логике, то и добавлять нужно методом PUT, что не верно.
Если нужно еще и создавать таблицы, то это PUT, если удалять — DELETE.
Также не забудьте про корректную обработку ошибок транзакций, как если базу сразу начнут редактировать несколько клиентов плюс ещё сам сервер в придачу.
Только как в SVN — перед тем, как добавить, желательно для начала обновить
URL/synchservice/ — возвращает текущую версию базы в формате, например, секунд прошедших с 1970 года;
URL/synchservice/tablename — возвращает полную таблицу так, как она есть в базе;
URL/synchservice/tablename/<current_version_on_client> — возвращает только изменения, произошедшие в таблице от момента current_version_on_client до текущей версии базы.
Этих методов должно хватить. В самом XML или JSON, который будете сериализовать, необходимо завести три секции — одну для записей, которые нужно вставить, вторую — удалить, третью — обновить. Это самый неизбыточный способ, по крайней мере это реально работает уже 2 года в довольно большой энтерпрайз-проекте.
Данные на стороне клиента желательно парсить SAX-парсером, т.к. дамп базы при первой синхронизации может быть достаточно большим. На сервер-сайде к каждой таблице нужно хранить таблицу истории со след. параметрами:
1. Операция (D — delete, I — insert, U — update)
2. Время операции.
3. ID записи в основной таблице.
И не забудьте проиндексировать по дате. Удачи!
Ну и API тоже не всегда простое — теперь бывают и очень сложные клиенты. На одном моем проекте было, например, более ста различных веб-сервисов с множеством параметров. В таких случаях автоматическая генерация очень помогает.
То же самое и с вашей статьёй — аналогии интересны, но всё, 90%, высосано из пальца. Возьмём ту же цикличность времени — вы почему-то возводите её в свойство времени, но это же абсолютный бред. Обращение планет вокруг звёзд (как и электронов вокруг ядра) ну вообще никак не зависит от свойств времени, это просто ещё один вид движения, описываемый вектором силы притяжения и центробежной силы.
Время относительно неподвижной частицы строго линейно, без всяких циклов. Относительно наблюдателя движущихся частиц — может замедляться, но до какого-то предела. Обратно не пойдёт, хотя бы потому что корень в формуле всегда положительный. Какой тут нафиг цикл?
Ну и дальше таким же образом. Бред…
1. Продуктовые, либо работающие с 1-2 крупными заказчиками. Там как нечего делать вылетит 60 человек в день.
2. Сервисные, с диверсифицированными заказами. Там намного стабильнее, но… и намного больше геморроя для кого-то.
Так что я добавил бы к списку автора ещё и «те люди, которые на PayPal аккаунт ставят пароли „paypal“».