Как стать автором
Обновить

Комментарии 22

Про API полезно знать любому тестировщику. Потому что по нему системы взаимодействуют между собой. И это взаимодействие вы видите каждый день даже на самых простых и захудалых сайтах.

Золотые слова! Применительно к нашей практике, то многие и многие сайты захудалые или нет (я говоря про сайты где так или иначе используются цифровые сертификаты и электронная подпись) не раскрывают сознательно или нет API, по которому с ними можно общаться. Они говорят возьми то-то и то-то, поставь и все будет работать. А это вообще-то говоря навязывание, отсюда коррупционные схемы и многое другое. И самое главное трудно предложить что-то новое и более совершенное и тем более перейти от MS Windows к отечественным ОС. Это и тормоз импортозамещению. Взгляните на требования к рабочему месту пользователя хоть ФНС, хоть ЕГАИС, хоть мною уважаемые ГОСУСЛУГИ и вы поймете, что до открытости API ой как далеко.

А что с ЕГАИС? Насколько помню там не такой уж и большой список требований

Мы же говорим не про требования к рабочему месту, кто хочет получить доступ в ЕГАИС, а про API, на котором все разработано.
А что ЕГАИС? Да, там не так все плохо и можно использовать токены PKCS#11 с ГОСТ-ами. Но все работает только под Windows, а это уже нехорошо.

Насчёт требования к ОС соглашусь. Но насчет API не так уверен. API у ЕГАИС идут для связи с ККТ (контрольно-кассовой техникой) и получением ТТН (Товарно-транспортной накладной) и остальных документов и поработав с ЕГАИС, я не заметил каких-то проблем с этим (кроме тех, когда пользователи сами косячат с номерами, информацией и прочим).

Согласитесь, ведь было бы совсем здорово, если бы ЕГАИС-у было безразницы на какой платформе работает пользователь. Кстати, ведь все социальные сети не зависят от платформу пользователя, наш же с вами Хабр.
Понимаете, помимо Linux, есть еще увлеченные люди, которые кроме OS X ничего признавать не хотят.

Согласен, при кроссплатформенности ПО ЕГАИС было бы лучше для рядового потребителя ввиду меньших затрат на технику при постоянной работе на Linux.
С другой стороны были бы проблемы с доработкой ПО и обучением работы на нем. Ведь большинство программ, даже для тех же мобильников структура программ и их функционал различен. А если какие-нибудь, допустим партнеры 1С, предоставляют услуги сопровождения предприятия в ЕГАИС, то работнику будет немного проблемно работать минимум на 2 ОС и перестраиваться между ними. Не смотря даже на тоже набор API
С другой стороны были бы проблемы с доработкой ПО и обучением работы на нем. Ведь большинство программ, даже для тех же мобильников структура программ и их функционал различен.

А тут вы не правы. Возьмите API PKCS#11 и сделайте всю работу с криптографией (включая создание и проверку подписи) на нем и все будет Ok.
Посмотрите сами хотя бы это (здесь пока три платформы). Программы и функционал для всех платформ одинаков.

Возможно мог ошибиться, а что насчет сопутствующего ПО и минимальных требований к ЕГАИС? Jacarta, если не ошибаюсь, без проблем и на Linux подобных работать.
А с остальным, в т.ч. и УТМ и 1С есть много проблем, даже на том же Linux, как с установкой, так и с обновлением.
Если распространять ЕГАИС и остальное на другие ОС, то надо будет дорабатывать само ПО и поддерживать эго
Jacarta, если не ошибаюсь, без проблем и на Linux подобных работать.

Нет, не ошибаетесь. И OS X тоже поддерживается.


надо будет дорабатывать само ПО и поддерживать эго

Именно про это я и говорю.

А будет ли целесообразно дорабатывать ПО для ОС с % рабочих мест порядка 25%, даже при наличии всего набора API

А как же права меньшинств?

А как же миллионные затраты на доработку и поддержку?

Правительство требует импортозамещение, а оно знает, что делает. -)

Думаю, надо согласиться с вами, т.к. со знающим человеком лучше не спорить

Спасибо за комплимент!

В жестоком реальном мире помимо «что на вход», «что на выходе» и «что делает» есть ещё потребность в описании возможных состояний системы. Даже если хочется делать 100% RESTful…
Да вообще потребность во внятном описании есть, да!

Вот для этого есть DbC (https://en.wikipedia.org/wiki/Design_by_contract). Там правда засада в том, что если уж вы все контракты верифицировали, то тестировать API скорее всего смысла нет.

Отличная статья! Большое спасибо, все очень понятно и простым языком. Супер
Спасибо за фидбек!:)
Спасибо за статью! отличное объяснение.
Спасибо за отзыв ))
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.