Коротко: мы поняли, как делать удобнее. А я — как стать лучше:
1) Когда я начал заниматься им, собирал информацию, о чем просили клиенты когда-то: какие-то дополнения, фишки, скриптики. И в процессе создания АПИ я понял, что это все возможно. Нет ограничений, ты свободный художник. Вопрос лишь в ресурсах (ну и борьбе с ленью, конечно).
2) Понял, как интересно общение с клиентами. Это невероятное чувство, когда тебе клиент пишет какую-то задумку, и вместе с ним ты погружаешься в эту идею и помогаешь ему, в том числе с кодом.
3) Ну и пару лет назад не поверил бы, что смогу написать свою систему управления документацией. И это [извините]
Нет, речь не про 200 код. Я про то, что если в ответе пришло что-то наподобие success или большой набор полей – понятно, что запрос не отвалился. Вот понять, что «он скорее жив» или наоборот – это уже следующая задача.
"goods_list":{
"1":{
"entry_is_in_discount":1,
"entry_weight":{
"weight":0,
"weight_raw":"0.0000"
},
"entry_stock":{
"stock_total":"0",
"stock":3
},
"entry_brief":"Если вам нужен красивый и запоминающийся UIN, этот товар для Вас.\r Данный товар имеет тип \"Электронный код\". Это означает, что пользователь после оплаты получит код, указанный при создании товара. Один код может быть куплен один раз."
Думаю, ваш вариант по поводу кольцевого тестирования – да, вероятно, помог бы в этой ситуации. Буду думать, спасибо.
«А запрос там вообще не отвалился? Он вообще что-нибудь отдает?» — это случай для автотестов. Но, как я писал в постскриптуме, само по себе апи очень чувствительно относится к любым имениям для веб-версии.
Например, после недавнего обновления мы обнаружили забавный баг: ответ от API приходил и вроде бы все хорошо… но данные для одного поля он выдавал вообще левые. Вопрос – а как быть в таких случаях? Пока лучше ручного теста – не нашли. Заодно ребята-тестировщики обучаются составлению запросов и другим интересным вещам.
М.б. чем-то пользуетесь/планируете и т.п., например:
Swagger, apiary или apiblueprint?
Да, мы знали о них, но тут я решил прокачать свой скилл, а не использовать готовое. Сейчас система работает правильно, ошибок не наблюдается. Теоретически, ее можно развивать и использовать и как отдельный продукт, и для других документаций внутри нашей компании. Если будем где-то еще использовать, обязательно сравню и сделаю обзор
Максим, в случае с zip мы исходили из того, как будет удобно ядру аудитории. По форуму, по опыту техподдержки выяснили – многим клиентам лучше именно в архиве подать файлы и написать документацию в вебе. Хотя гитхаб – это, конечно, позитивно, хорошо и правильно
Интересно, что под капотом?
Оно как-то само собирается и т.п. и т.д., или есть ещё к этому редактор?
Под капотом PHP в связке с MySQL.
Как и в случае с примером про полуавтоматическое созданием приложения, я заленился и сделал себе инструменты, чтобы «просто выбрал, заполнил – и в продакшен». Есть внутренняя админка на меня одного, и в ней даже не нужно настраивать некий краудин, чтобы делать транслэйторам переводы.
Т.е. весь проект документации – полностью самописная вещь, которой удобно пользоваться лично мне. Но как знать, может, в будущем попробую сделать из этого отдельный проект.
1) Когда я начал заниматься им, собирал информацию, о чем просили клиенты когда-то: какие-то дополнения, фишки, скриптики. И в процессе создания АПИ я понял, что это все возможно. Нет ограничений, ты свободный художник. Вопрос лишь в ресурсах (ну и борьбе с ленью, конечно).
2) Понял, как интересно общение с клиентами. Это невероятное чувство, когда тебе клиент пишет какую-то задумку, и вместе с ним ты погружаешься в эту идею и помогаешь ему, в том числе с кодом.
3) Ну и пару лет назад не поверил бы, что смогу написать свою систему управления документацией. И это [извините]
Покажу на примере, про который говорил:
Поступало:
Должно было:
Думаю, ваш вариант по поводу кольцевого тестирования – да, вероятно, помог бы в этой ситуации. Буду думать, спасибо.
Например, после недавнего обновления мы обнаружили забавный баг: ответ от API приходил и вроде бы все хорошо… но данные для одного поля он выдавал вообще левые. Вопрос – а как быть в таких случаях? Пока лучше ручного теста – не нашли. Заодно ребята-тестировщики обучаются составлению запросов и другим интересным вещам.
Возможно, нам стоит задуматься на тему – документация с github, документация с zip. Как я и говорил, это тема, которую сложно перестать развивать
Да, мы знали о них, но тут я решил прокачать свой скилл, а не использовать готовое. Сейчас система работает правильно, ошибок не наблюдается. Теоретически, ее можно развивать и использовать и как отдельный продукт, и для других документаций внутри нашей компании. Если будем где-то еще использовать, обязательно сравню и сделаю обзор
Под капотом PHP в связке с MySQL.
Как и в случае с примером про полуавтоматическое созданием приложения, я заленился и сделал себе инструменты, чтобы «просто выбрал, заполнил – и в продакшен». Есть внутренняя админка на меня одного, и в ней даже не нужно настраивать некий краудин, чтобы делать транслэйторам переводы.
Т.е. весь проект документации – полностью самописная вещь, которой удобно пользоваться лично мне. Но как знать, может, в будущем попробую сделать из этого отдельный проект.