Сообщение Re[12]: REST: прохой\хороший интерфейс от 13.02.2020 3:45
Изменено 13.02.2020 4:22 Pavel Dvorkin
Re[12]: REST: прохой\хороший интерфейс
Здравствуйте, Sinclair, Вы писали:
S>Ну вот. При этом инкрементальность приходилось велосипедить самому. И вряд ли удалось сначала сделать протокол без инкрементальности, а потом добавить к нему инкрементальность обратно-совместимым способом.
Инкрементальность была заложена задачей, поэтому проектировалось с ней сразу.
S>Павел, очень, очень советую почитать литературу. Ссылка на бесплатную книжку приведена прямо в этом топике. "Свобода" RPC означает, по большому счёту, свободу писать некорректные и неоптимизируемые протоколы.
Спасибо за совет
PD>>HTTP — какой глагол употребим ?
S>С точки зрения HTTP, совершенно неважно, что там происходит "на сервере". Важно то, как мы это представляем клиенту. Representational State Transfer. Если клиенту выставляется такая модель ресурсов, что при применении этого действия к модели добавляется новый ресурс, то делаем через PUT.
S>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
S>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.
Пожалуйста. Сразу прошу прощения за небольшие отклонения от классика , сделаны для пущей выразительности.
На сервер города N добавляется новая Персона. Все, что о ней известно на момент ее поступления на сервер — инкогнито, недурной наружности, в партикулярном платье, ходит этак по комнате, и в лице этакое рассуждение... физиономия... поступки, и здесь (вертит рукою около лба) много, много всего.
С использованием методов машинного интеллекта при участии персон Городничего, Ляпкина-Тяпкина, Добчинского и Бобчинского производится классификация этой Персоны — относится ли она к категории Ревизоры
Если эта классификация отнесет его к категории Ревизор, то необходимо
1. Надеть колпаки на больных в богоугодном заведении и проследить, чтобы они были чистыми
2. Сделать, чтобы больные не походили бы на кузнецов
3. Над каждой кроватью написать по-латыни название болезни
4. Удалить всех гусей с гусенками из присутственных мест, а также удалить охотничий арапник там же
5. Провести воспитательную беседу с учителями (алгоритм TBD) и особо им указать, чтобы стулья не ломали
6. Сказать Держиморде, чтобы не слишком давал воли кулакам своим
7. Подготовить некую сумму денег для взятки.
Попутно должен быть выяснен вопрос о войне с турками и в случае положительного решения выяснить, нет ли в город измены. Впрочем, метод машиннного интеллекта определил, что войны с турками все же не будет.
Если же он не Ревизор, то все, что надо — записать его в книгу проезжающих и предоставить собственной судьбе.
Так что же это — POST, PUT или DELETE ? И чего именно ?
PD>>RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.
S>Я вас умоляю. DCOM/OLE работает в тепличных условиях локальной машины. В нём ситуация "не удалось доставить результат вызова обратно" — редкость. И когда она случается, результат лечат перезагрузкой машины.
COM работает в условиях локальной машины, а DCOM — это Distributed COM, работает в локальной сети.
S>Использовать DCOM через океан — упаси байт! Представь себе приложение резервирования авиабилетов, написанное на DCOM. Или хотя бы онлайн-регистрации. Нафиг-нафиг.
Причин же, почему DCOM для этого не используется , три
1. HTTP был сделан раньше, вот его и продолжвли использовать
2. COM нет в линуксе, что сразу ставит крест на возможности его использования для этой цели
3. COM не подерживают все браузеры даже в Windows.
S>Ну вот. При этом инкрементальность приходилось велосипедить самому. И вряд ли удалось сначала сделать протокол без инкрементальности, а потом добавить к нему инкрементальность обратно-совместимым способом.
Инкрементальность была заложена задачей, поэтому проектировалось с ней сразу.
S>Павел, очень, очень советую почитать литературу. Ссылка на бесплатную книжку приведена прямо в этом топике. "Свобода" RPC означает, по большому счёту, свободу писать некорректные и неоптимизируемые протоколы.
Спасибо за совет
PD>>HTTP — какой глагол употребим ?
S>С точки зрения HTTP, совершенно неважно, что там происходит "на сервере". Важно то, как мы это представляем клиенту. Representational State Transfer. Если клиенту выставляется такая модель ресурсов, что при применении этого действия к модели добавляется новый ресурс, то делаем через PUT.
S>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
S>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.
Пожалуйста. Сразу прошу прощения за небольшие отклонения от классика , сделаны для пущей выразительности.
На сервер города N добавляется новая Персона. Все, что о ней известно на момент ее поступления на сервер — инкогнито, недурной наружности, в партикулярном платье, ходит этак по комнате, и в лице этакое рассуждение... физиономия... поступки, и здесь (вертит рукою около лба) много, много всего.
С использованием методов машинного интеллекта при участии персон Городничего, Ляпкина-Тяпкина, Добчинского и Бобчинского производится классификация этой Персоны — относится ли она к категории Ревизоры
Если эта классификация отнесет его к категории Ревизор, то необходимо
1. Надеть колпаки на больных в богоугодном заведении и проследить, чтобы они были чистыми
2. Сделать, чтобы больные не походили бы на кузнецов
3. Над каждой кроватью написать по-латыни название болезни
4. Удалить всех гусей с гусенками из присутственных мест, а также удалить охотничий арапник там же
5. Провести воспитательную беседу с учителями (алгоритм TBD) и особо им указать, чтобы стулья не ломали
6. Сказать Держиморде, чтобы не слишком давал воли кулакам своим
7. Подготовить некую сумму денег для взятки.
Попутно должен быть выяснен вопрос о войне с турками и в случае положительного решения выяснить, нет ли в город измены. Впрочем, метод машиннного интеллекта определил, что войны с турками все же не будет.
Если же он не Ревизор, то все, что надо — записать его в книгу проезжающих и предоставить собственной судьбе.
Так что же это — POST, PUT или DELETE ? И чего именно ?
PD>>RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.
S>Я вас умоляю. DCOM/OLE работает в тепличных условиях локальной машины. В нём ситуация "не удалось доставить результат вызова обратно" — редкость. И когда она случается, результат лечат перезагрузкой машины.
COM работает в условиях локальной машины, а DCOM — это Distributed COM, работает в локальной сети.
S>Использовать DCOM через океан — упаси байт! Представь себе приложение резервирования авиабилетов, написанное на DCOM. Или хотя бы онлайн-регистрации. Нафиг-нафиг.
Причин же, почему DCOM для этого не используется , три
1. HTTP был сделан раньше, вот его и продолжвли использовать
2. COM нет в линуксе, что сразу ставит крест на возможности его использования для этой цели
3. COM не подерживают все браузеры даже в Windows.
Re[12]: REST: прохой\хороший интерфейс
Здравствуйте, Sinclair, Вы писали:
S>Ну вот. При этом инкрементальность приходилось велосипедить самому. И вряд ли удалось сначала сделать протокол без инкрементальности, а потом добавить к нему инкрементальность обратно-совместимым способом.
Инкрементальность была заложена задачей, поэтому проектировалось с ней сразу.
S>Павел, очень, очень советую почитать литературу. Ссылка на бесплатную книжку приведена прямо в этом топике. "Свобода" RPC означает, по большому счёту, свободу писать некорректные и неоптимизируемые протоколы.
Спасибо за совет
PD>>HTTP — какой глагол употребим ?
S>С точки зрения HTTP, совершенно неважно, что там происходит "на сервере". Важно то, как мы это представляем клиенту. Representational State Transfer. Если клиенту выставляется такая модель ресурсов, что при применении этого действия к модели добавляется новый ресурс, то делаем через PUT.
S>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
S>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.
Пожалуйста. Сразу прошу прощения за небольшие отклонения от классика , сделаны для пущей выразительности.
На сервер города N добавляется новая Персона. Все, что о ней известно на момент ее поступления на сервер — инкогнито, недурной наружности, в партикулярном платье, ходит этак по комнате, и в лице этакое рассуждение... физиономия... поступки, и здесь (вертит рукою около лба) много, много всего.
С использованием методов машинного интеллекта при участии персон Городничего, Ляпкина-Тяпкина, Добчинского и Бобчинского производится классификация этой Персоны — относится ли она к категории Ревизоры
Если эта классификация отнесет его к категории Ревизор, то необходимо
1. Надеть колпаки на больных в богоугодном заведении и проследить, чтобы они были чистыми
2. Сделать, чтобы больные не походили бы на кузнецов
3. Над каждой кроватью написать по-латыни название болезни
4. Удалить всех гусей с гусенками из присутственных мест, а также удалить охотничий арапник там же
5. Провести воспитательную беседу с учителями (алгоритм TBD) и особо им указать, чтобы стулья не ломали
6. Сказать Держиморде, чтобы не слишком давал воли кулакам своим
7. Подготовить некую сумму денег для взятки.
Попутно должен быть выяснен вопрос о войне с турками и в случае положительного решения выяснить, нет ли в город измены. Впрочем, метод машиннного интеллекта определил, что войны с турками все же не будет.
Если же он не Ревизор, то все, что надо — записать его в книгу проезжающих и предоставить собственной судьбе.
Так что же это — POST, PUT или DELETE ? И чего именно ?
Для RPC —
class Person {
String наружность;
String платье;
//...
}
void addPerson(Person person);
а там уж что будет, то и будет.
PD>>RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.
S>Я вас умоляю. DCOM/OLE работает в тепличных условиях локальной машины. В нём ситуация "не удалось доставить результат вызова обратно" — редкость. И когда она случается, результат лечат перезагрузкой машины.
COM работает в условиях локальной машины, а DCOM — это Distributed COM, работает в локальной сети.
S>Использовать DCOM через океан — упаси байт! Представь себе приложение резервирования авиабилетов, написанное на DCOM. Или хотя бы онлайн-регистрации. Нафиг-нафиг.
Причин же, почему DCOM для этого не используется , три
1. HTTP был сделан раньше, вот его и продолжвли использовать
2. COM нет в линуксе, что сразу ставит крест на возможности его использования для этой цели
3. COM не подерживают все браузеры даже в Windows.
S>Ну вот. При этом инкрементальность приходилось велосипедить самому. И вряд ли удалось сначала сделать протокол без инкрементальности, а потом добавить к нему инкрементальность обратно-совместимым способом.
Инкрементальность была заложена задачей, поэтому проектировалось с ней сразу.
S>Павел, очень, очень советую почитать литературу. Ссылка на бесплатную книжку приведена прямо в этом топике. "Свобода" RPC означает, по большому счёту, свободу писать некорректные и неоптимизируемые протоколы.
Спасибо за совет
PD>>HTTP — какой глагол употребим ?
S>С точки зрения HTTP, совершенно неважно, что там происходит "на сервере". Важно то, как мы это представляем клиенту. Representational State Transfer. Если клиенту выставляется такая модель ресурсов, что при применении этого действия к модели добавляется новый ресурс, то делаем через PUT.
S>На всякий случай поясню, что такие вопросы обсуждать бессмысленно. Конструктивную беседу можно вести только в рамках более-менее очерченной задачи.
S>Придумай задачу, для которой тебе кажется естественным некий RPC-API (можешь сразу и набросать его черновик), а REST-API вызывает затруднения. Я покажу, как сделать REST для этой задачи, и можно будет сравнить достоинства и недостатки.
Пожалуйста. Сразу прошу прощения за небольшие отклонения от классика , сделаны для пущей выразительности.
На сервер города N добавляется новая Персона. Все, что о ней известно на момент ее поступления на сервер — инкогнито, недурной наружности, в партикулярном платье, ходит этак по комнате, и в лице этакое рассуждение... физиономия... поступки, и здесь (вертит рукою около лба) много, много всего.
С использованием методов машинного интеллекта при участии персон Городничего, Ляпкина-Тяпкина, Добчинского и Бобчинского производится классификация этой Персоны — относится ли она к категории Ревизоры
Если эта классификация отнесет его к категории Ревизор, то необходимо
1. Надеть колпаки на больных в богоугодном заведении и проследить, чтобы они были чистыми
2. Сделать, чтобы больные не походили бы на кузнецов
3. Над каждой кроватью написать по-латыни название болезни
4. Удалить всех гусей с гусенками из присутственных мест, а также удалить охотничий арапник там же
5. Провести воспитательную беседу с учителями (алгоритм TBD) и особо им указать, чтобы стулья не ломали
6. Сказать Держиморде, чтобы не слишком давал воли кулакам своим
7. Подготовить некую сумму денег для взятки.
Попутно должен быть выяснен вопрос о войне с турками и в случае положительного решения выяснить, нет ли в город измены. Впрочем, метод машиннного интеллекта определил, что войны с турками все же не будет.
Если же он не Ревизор, то все, что надо — записать его в книгу проезжающих и предоставить собственной судьбе.
Так что же это — POST, PUT или DELETE ? И чего именно ?
Для RPC —
class Person {
String наружность;
String платье;
//...
}
void addPerson(Person person);
а там уж что будет, то и будет.
PD>>RPC, с твоего разрешения, лежит под DCOM/OLE (ты это должен знать), а там гораздо более сложная логика, чем в бизнес-приложениях. Убери RPC — и Windows больше нет.
S>Я вас умоляю. DCOM/OLE работает в тепличных условиях локальной машины. В нём ситуация "не удалось доставить результат вызова обратно" — редкость. И когда она случается, результат лечат перезагрузкой машины.
COM работает в условиях локальной машины, а DCOM — это Distributed COM, работает в локальной сети.
S>Использовать DCOM через океан — упаси байт! Представь себе приложение резервирования авиабилетов, написанное на DCOM. Или хотя бы онлайн-регистрации. Нафиг-нафиг.
Причин же, почему DCOM для этого не используется , три
1. HTTP был сделан раньше, вот его и продолжвли использовать
2. COM нет в линуксе, что сразу ставит крест на возможности его использования для этой цели
3. COM не подерживают все браузеры даже в Windows.