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

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

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

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

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

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


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

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


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

В моем примере у каждого метода своя процедура, править легко.
Прикрепленные файлы:
14. blackhole321 1039 07.08.18 08:37 Сейчас в теме
(10)и..?
Вы считаете более разумным запихнуть все из Вашего принтскрина в один метод?
15. dsdred 1218 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 1269 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 1218 06.08.18 22:30 Сейчас в теме
(3)
В примере который я описал в статье труда не составит отрабатывать по Вашему.
ЗаполнитьСтруктуруОтвета(СтруктураОтвет,200,"{""status"":404,""msg"":""account not found""}",ложь,"");

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


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

Только вот выдача лицензий сервером 1С тратит лицензию на каждое подключение. Запустил базу два раза - сожрал две лицензии. Запустил четыре базы - сожрал четыре лицензии.
12. dsdred 1218 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 1218 15.08.18 16:12 Сейчас в теме
(17)
Есть еще одно но при использовании HTTP, не все админы любят когда сервак где установлена 1С ка смотрит в мир и часто это дело закрывают. Поэтому достучаться можно только через внутреннюю сеть. Выходит, что надо тогда ставить отдельный сервак который будет смотреть в мир, иначе никак )


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


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

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

Вакансии

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

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

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

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