0. dsdred 1219 05.06.18 22:06 Сейчас в теме

HTTP Сервисы: Путь к своему сервису. Часть 1

Уже много было написано про http-сервисы, но то и дело всплывают «Новые» статьи по обмену между базами V8 по COM, что «Немножко» удивляет. Решил внести свои 5 копеек, поработаем с http-сервисом.

Перейти к публикации

Комментарии
Избранное Подписка Сортировка: Древо
1. blackhole321 1040 16.07.18 08:03 Сейчас в теме
Видно, что создано два Шаблона с методом Get, но по большому счету отличаются они только тем, что один ищет по номеру документ, а второй выводит все.

Все это можно реализовать одним методом


Возможно авторы хотели изолировать эти методы, чтобы было проще вносить правки в дальнейшем. Иначе, есть риск, что Ваш один метод со временем примет монстрообразный вид.
Snegurochka; zuxelzz; +2 Ответить
2. capitan 1276 16.07.18 09:38 Сейчас в теме
«comcntr.dll» забываем как страшный сон!

Напоминает Хрущева и его попытки засеять страну кукурузой.
HTTP сервисы и COM совершенно разные технологии, нет смысла их противопоставлять.
Начиная с того, что разные стороны выступают в логи ведущего.
Делать все на HTTP так же бессмысленно, как и делать все на COM
В вашей же терминологии- это как вдруг слетать на самолете на работу вместо того чтобы на маршрутке доехать
Ну и маленькая ложечка дегтя - попробуйте тысяч десять строк передать по HTTP ,а потом порадуете сообщество быстродействием.
если конечно индеец раньше не ляжет )
alex-l19041; lepth; LordKim; sbcode; A7_Sash; cdrw3; Tavalik; +7 Ответить
7. Silenser 509 18.07.18 14:18 Сейчас в теме
(2)
Ну и маленькая ложечка дегтя - попробуйте тысяч десять строк передать по HTTP ,а потом порадуете сообщество быстродействием.
если конечно индеец раньше не ляжет )
Как мне кажется, вопрос не в количестве строк, а в объеме пакета. В IIS ограничение, вроде бы, 30 Мб, хотя как утверждают некоторые разработчики на форумах, вопрос производительности начинает быть актуальным уже после 10 Мб. С вашей идеей в целом согласен, разные инструменты для разных задач.
11. dsdred 1219 06.08.18 14:49 Сейчас в теме
(2)
Напоминает Хрущева и его попытки засеять страну кукурузой.


Забавное сравнение. Спасибо, посмеялся.

Делать все на HTTP так же бессмысленно

Я про все не говорю, но мне лично непонятны вот такие статьи (https://infostart.ru/public/827371/) от мая 2018,
при чем радует, что статья ссылается на свежую статью 2012 года

Ну и маленькая ложечка дегтя - попробуйте тысяч десять строк передать по HTTP ,а потом порадуете сообщество быстродействием.
если конечно индеец раньше не ляжет )


Дегтя не уловил. Специально глянул сейчас один из сервисов который делал для крупной сети. Смыл в том, что из УТ10 забираю данные раз в час по оптовому складу продажи за день и свободные остатки на текущий момент и там порядка 20К строк, забираю за 30-120 секунд.

Вообще http-сервисы, как ниже было замечено ограничены не количеством строк а размером передаваемого сообщения, ограничение настроено на стороне веб сервера и в случае с IIS можно вот тут например посмотреть как его сделать больше или меньше (https://infostart.ru/public/427026/)

Ну и так же никто не запрещает использовать порции. Ну и формат сообщения тоже влияет на объем, оптимально использовать JSON.

П.С. Хотел в следующих частях про эти вещи говорить...
10. dsdred 1219 06.08.18 14:22 Сейчас в теме
(1)
Возможно авторы хотели изолировать эти методы, чтобы было проще вносить правки в дальнейшем. Иначе, есть риск, что Ваш один метод со временем примет монстрообразный вид.


Как раз таки монстрообразный вид это если сделать так как на ИТС пример написан.
Приложу прин скрин 4-х летней давности, когда я только изучал веб-сервисы.

В моем примере у каждого метода своя процедура, править легко.
Прикрепленные файлы:
14. blackhole321 1040 07.08.18 08:37 Сейчас в теме
(10)и..?
Вы считаете более разумным запихнуть все из Вашего принтскрина в один метод?
15. dsdred 1219 08.08.18 15:07 Сейчас в теме
(14) Если кратко ответить, то да. Что-то в GET, что-то в POST.

А вообще то, что я считаю разумным у меня в процессе разработки.
3. ArchLord42 68 16.07.18 12:43 Сейчас в теме
Важно: Хотелось бы обратить внимание на коды состояния из примера выше. Мне раза три в моей практике попадались API, которые всегда возвращали ответ с кодом 200 (200 OK («хорошо»)) и только в теле ответа, можно было понять, была ли ошибка. Это грубейшая ошибка разработчиков! Ну или это неуважение к конечному потребителю...


Вообще-то это не фига не грубейшая ошибка и не неуважение к потребителю API, сразу видно что с построением архитектуры HTTP сервисов вы знакомы плохо, много где (в книгах, в блогах, на стэковерфлоу) уже давно разжеваны причины такого подхода.

Простой пример: мы хотим получить данные учетной записи, отправляя запрос на account/{guid}

Я запрашиваю /account/123, мне сервис возвращает { status: 400, msg: "incorrect guid" }, я точно понимаю, что я ввел не верный гуид
Я запрашиваю /account/t140762c2-0742-4046-9a0e-c4f81931c549 мне возвращает { status: 404, msg: "account not found" }, я точно понимаю, что акка с таким гуидом нету

Все что было выше - это ошибки БИЗНЕС логики

А теперь я запрашиваю /accounttttt/t140762c2-0742-4046-9a0e-c4f81931c549
и мне тупо возращается HTTP код 404 и тут я понимаю, что я накосячил с УРЛом
Это ошибка транспорта HTTP

Как итог: в первом и втором случае, запрос прошел корректно, сервер его корректно обработал и вернул ответ с ошибкой в бизнес логики.
В третьем запросе, запрос не дошел даже до сервера, он его не обработал в принципе и я получил ошибку 404, а то, что коды ошибок совпадают с HTTP кодами, так это как раз из уважения к потребителям, т.к. примерно понятен смысл без всяких доп.сообщений, а постоянно возвращающийся ответ с 200 кодом, означает, что траспорт информации по HTTP от клиента до сервера прошел корректно и сервер его корректно обработал.

ЗЫ. Конечно постоянно возвращать 200, даже когда на сервере произошла ошибка это предмет многих холиваров, вот например когда использование кодов является хорошим тоном.
200 - тут все ясно
400 - Bad Request, ошибка клиента - выдавать например при ошибке парсинга JSON (в случае когда он не валидиный) или это вообще не JSON
401 - Unauthorized - тут думаю тоже все ясно,
500 - Internal Server Error - Все необработанные ошибки сервера
Anton64; pbabincev; saa@kuzov.org; Smaylukk; sbcode; addict2blood; JohnyDeath; AlexGroovy; Danil.Potapov; baton_pk; fr13; kuntashov; capitan; +13 Ответить
4. capitan 1276 16.07.18 14:23 Сейчас в теме
5. CSiER 27 18.07.18 05:57 Сейчас в теме
(3)
Вообще-то это не фига не грубейшая ошибка и не неуважение к потребителю API, сразу видно что с построением архитектуры HTTP сервисов вы знакомы плохо, много где (в книгах, в блогах, на стэковерфлоу) уже давно разжеваны причины такого подхода.

Интерпретировать это как ошибку или нет зависит от того, как именно используется HTTP (только как транспорт или в качестве RESTful api), имхо. Ваш пример ближе к транспорту, у автора публикации - к REST.

(3)
ЗЫ. Конечно постоянно возвращать 200, даже когда на сервере произошла ошибка это предмет многих холиваров, вот например когда использование кодов является хорошим тоном.

- аналогично, все зависит от того, как именно предполагается использовать API. На мой взгляд, здесь автор API решает как делать правильно (можно и 200 всегда возвращать и только get, а описание ошибки в ответе) - главное чтобы это все было хорошо описано, например, с помощью apiary.io.
13. dsdred 1219 06.08.18 22:30 Сейчас в теме
(3)
В примере который я описал в статье труда не составит отрабатывать по Вашему.
ЗаполнитьСтруктуруОтвета(СтруктураОтвет,200,"{""status"":404,""msg"":""account not found""}",ложь,"");

Ну а вообще, отличить ошибку Бизнес логики от ошибки возвращаемой веб сервером, думаю труда не составит, но спорить с Вами не буду, так как
это предмет многих холиваров
6. addict2blood 18.07.18 10:19 Сейчас в теме
Самый главный минус. Нужно установить и настроить веб сервер


Самый главный минус это выдача лицензий сервером 1С
8. capitan 1276 18.07.18 17:08 Сейчас в теме
(6)все смешалось в доме облонских...
на HTTP лицензия не расходуется
9. addict2blood 26.07.18 11:20 Сейчас в теме
(8) А я не писал, что HTTP лицензия расходуется.

Только вот выдача лицензий сервером 1С тратит лицензию на каждое подключение. Запустил базу два раза - сожрал две лицензии. Запустил четыре базы - сожрал четыре лицензии.
12. dsdred 1219 06.08.18 14:55 Сейчас в теме
(9) Не понимаю к чему Вы это написали...
16. WKBAPKA 211 15.08.18 11:18 Сейчас в теме
(8) я тоже читал, что при использовании HTTP лицензия расходуется, не расходуется при использовании WEB-Сервиса.
Передавал каталог товаров в формате JSON, сервер Apache, пока с ограничением не столкнулся.
17. WKBAPKA 211 15.08.18 11:21 Сейчас в теме
Есть еще одно но при использовании HTTP, не все админы любят когда сервак где установлена 1С ка смотрит в мир и часто это дело закрывают. Поэтому достучаться можно только через внутреннюю сеть. Выходит, что надо тогда ставить отдельный сервак который будет смотреть в мир, иначе никак )
18. dsdred 1219 15.08.18 16:12 Сейчас в теме
(17)
Есть еще одно но при использовании HTTP, не все админы любят когда сервак где установлена 1С ка смотрит в мир и часто это дело закрывают. Поэтому достучаться можно только через внутреннюю сеть. Выходит, что надо тогда ставить отдельный сервак который будет смотреть в мир, иначе никак )


Да еще есть мелочи и нюансы с которыми должны по идее справляться админы, к примеру организовать https. В моем текущем месте работы админы такие которые у нас административную часть спрашивают как сделать... Хуже этих слава богу еще не встречал.
19. WKBAPKA 211 15.08.18 20:15 Сейчас в теме
(18)https не поможет, если будут бомбить сервер
20. dsdred 1219 15.08.18 21:14 Сейчас в теме
(19)Ну DDoS-атака это уже отдельный вопрос администрирования.
21. WKBAPKA 211 16.08.18 10:12 Сейчас в теме
(20)согласитесь, поставить отдельный сервачек будет дешевле, чем пытаться потом решать проблемы взлома сервера ?
22. dsdred 1219 17.08.18 21:53 Сейчас в теме
(21)
согласитесь, поставить отдельный сервачек будет дешевле, чем пытаться потом решать проблемы взлома сервера ?


А кто спорит то? Согласен на все 100%.

Вопрос обычно к жадности владельца бизнеса. Бывают случае когда скупой решает "Сэкономить" на персонале и железе в итоге затраты в разы выше если, что то случается.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Автор новостных обзоров на тему 1С и бухучета
Санкт-Петербург
По совместительству

Ведущий программист 1С
Санкт-Петербург
зарплата от 130 000 руб.
Полный день

Программист 1С
Москва
зарплата от 130 000 руб. до 200 000 руб.
Полный день

Бизнес-архитектор 1С, ведущий консультант
Санкт-Петербург
Полный день

Руководитель проектов 1С
Санкт-Петербург
Полный день