Здравствуйте, gandjustas, Вы писали:
GZ>>Или такой сценарий: GZ>>В ответ на документ, пользователь пишет письмо, и прикладывает другой документ. При этом письмо — не является документом, и принадлежит иерархии профайла пользователя, а не документов. Как их сохранить эти две сущности согласованно? G>Пусть документы у нас адресуются по /Document(id), а а писма по /Detter(id). G>Никто не мешает выполнять указанный тобой сценарий с помощью POST на url /Document(someId)/responceLetter G>В запостенном объекте должны быть все приложенные документы (или ссылки на них).
Эмулировать запуск сценария с помощью объекта? Прикольно.
Здравствуйте, GlebZ, Вы писали: GZ>Эмулировать запуск сценария с помощью объекта? Прикольно.
Так это и есть вся идея REST. Там в принципе нет никаких других глаголов, кроме Получить, Изменить, Добавить, Удалить (где-то это уже встречалось...).
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, gandjustas, Вы писали:
GZ>>>Или такой сценарий: GZ>>>В ответ на документ, пользователь пишет письмо, и прикладывает другой документ. При этом письмо — не является документом, и принадлежит иерархии профайла пользователя, а не документов. Как их сохранить эти две сущности согласованно? G>>Пусть документы у нас адресуются по /Document(id), а а писма по /Detter(id). G>>Никто не мешает выполнять указанный тобой сценарий с помощью POST на url /Document(someId)/responceLetter G>>В запостенном объекте должны быть все приложенные документы (или ссылки на них). GZ>Эмулировать запуск сценария с помощью объекта? Прикольно.
Чего эмкулировать? Какого сценария?
Смотри:
Сохранить --------> POST
письмо --------> <тип объекта>
в ответ на документ --------> /Document(someId)/responseLetter
с прикрепленным документом --------> <поддерево обеъктов>
Способ реализации непосредственно из постановки задачи следует.
Здравствуйте, gandjustas, Вы писали:
G>Чего эмкулировать? Какого сценария?
G>Смотри: G>
G>Сохранить --------> POST
G>письмо --------> <тип объекта>
G>в ответ на документ --------> /Document(someId)/responseLetter
G>с прикрепленным документом --------> <поддерево обеъктов>
G>
G>Способ реализации непосредственно из постановки задачи следует.
Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере.
Здравствуйте, Sinclair, Вы писали:
S>Так это и есть вся идея REST. Там в принципе нет никаких других глаголов, кроме Получить, Изменить, Добавить, Удалить (где-то это уже встречалось...).
Токмо тут нет требования идемподентности. Зато сериализованность — весьма важна. Это и бросилось в глаза.
Здравствуйте, GlebZ, Вы писали: GZ>Токмо тут нет требования идемподентности.
Ага. Потому, что SQL всё же работает с реляциями, а не с отдельными строками. GZ>Зато сериализованность — весьма важна. Это и бросилось в глаза.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали:
GZ>Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере.
Это точка зрения. Представь себе язык программирования, где методов нету вообще, а есть только свойства. Уверяю тебя, ты быстро научишься писать на нём произвольные программы.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
GZ>>Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере. S>Это точка зрения. Представь себе язык программирования, где методов нету вообще, а есть только свойства. Уверяю тебя, ты быстро научишься писать на нём произвольные программы.
Если ты проектируешь(развиваешь) проект от данных — то может быть и полезно. Если от действий пользователя(как я) — то я не нахожу здесь плюсов. Покамест никакого плюса, кроме адресуемости данных, я не вижу. Ито, это плюс достаточно абстрактный, так как за эту фичу мне денег не заплатят. По сравнению с более развитым интерфейсом — REST, это самоограничение.
Здравствуйте, GlebZ, Вы писали: GZ>Если ты проектируешь(развиваешь) проект от данных — то может быть и полезно. Если от действий пользователя(как я) — то я не нахожу здесь плюсов. Покамест никакого плюса, кроме адресуемости данных, я не вижу. Ито, это плюс достаточно абстрактный, так как за эту фичу мне денег не заплатят. По сравнению с более развитым интерфейсом — REST, это самоограничение.
Тут фишка вот в чём — проектировать от действий пользователя надо UI. А вот структура внутренней модели частенько оказывается лучше выразимой именно в терминах данных. Просто "действия" гораздо хуже масштабируются — для них крайне тяжело делать метавыводы, навроде "зависит ли результат от порядка выполнения двух таких-то действий".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, gandjustas, Вы писали:
G>>Чего эмкулировать? Какого сценария?
G>>Смотри: G>>
G>>Сохранить --------> POST
G>>письмо --------> <тип объекта>
G>>в ответ на документ --------> /Document(someId)/responseLetter
G>>с прикрепленным документом --------> <поддерево обеъктов>
G>>
G>>Способ реализации непосредственно из постановки задачи следует. GZ>Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере.
В не-REST случае оно как выглядеть будет?
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Sinclair, Вы писали:
GZ>>>Об этом и речь. В данном случае нам не нужен CRUD как таковой. Нам нужно действие выполняемое на сервере. S>>Это точка зрения. Представь себе язык программирования, где методов нету вообще, а есть только свойства. Уверяю тебя, ты быстро научишься писать на нём произвольные программы. GZ>Если ты проектируешь(развиваешь) проект от данных — то может быть и полезно. Если от действий пользователя(как я) — то я не нахожу здесь плюсов. Покамест никакого плюса, кроме адресуемости данных, я не вижу.
Ну приведи пример "действия пользователя", которое невозможно выразить в терминах получения\изменения состояния.
GZ>Ито, это плюс достаточно абстрактный, так как за эту фичу мне денег не заплатят. По сравнению с более развитым интерфейсом — REST, это самоограничение.
Если провести строгое разделение "действий" между командами и запросами (Query-Command Separation), то у тебя как раз получится недо-REST (фактически два типа запросов будут участвовать — GET и POST). REST как раз помогает сблизить "состояние" и "действия".
Зато сериализованность — весьма важна. Это и бросилось в глаза.
