Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Изучение API

Всем привет, вопрос к знатокам.
Есть желание и потребность в изучении API, да конечно, есть много статей для новичков и т.п., не удобно прыгать со статьи на статью. Так что, возможно кто-то может подсказать, где найти объёмное и структурированное руководство(может курс какой есть, уроки) для работы с этой технологией. Буду очень благодарен ответам по теме, да и критической оценке вопроса тоже!)

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Корисний гайд для початківців: zapier.com/learn/apis

Як правильно тестувати API:

1. Відкриваєш bash.
2. П****чиш команду sudo apt install curl
3. Копі****иш curl example зі stackoverflow.
4. Замінюєш змінні на ті шо видали кривожопі деви.
5. Жмеш enter.
6. Генериш репорт «Ні*** не працює, ошибка 500».
7. Вичитуєш нотації девів: «Ти курво неправильно тестуєш!».
8. Через деякий час сходитесь на тому, що ви оба п***юки.
9. Йдеш пити каву.

Чуваки, а що там вчити? Прочитав статю типу цьої: medium.com/...​-restful-api-cbe81b06f291 і пішов лячкати ендпоінти. Потім підключив Swagger і куяк його в паблік. І хай читають, кому треба.

Особливо просунуті можуть апдейтити стилі Swagger гуі під колір штанів начальства.

может, есть конкретный пример? сервис, система, сайт, протокол?

термин API означает концепцию. Типа как «интерфейс пользователя» или «документация». Термин слиииишком широкий и ни гуглить такое, ни изучать не возможно. Обычно, говорят о некоем протоколе. Например, API конкретного сайта(web-системы) может быть построено на базе протокола REST(логика формирования ответа, сопоставление URL и конкретных данных), который основывается на протоколе HTTP(концепция URL, http status, request body, response body, headers). Следовательно, можно искать статьи по тестированию REST API и применять навыки к конкретному сайту. Или гуглить тестирование HTTP API(и, возможно, попасть на статьи по тем же инструментам или все же чему-то другому, типа SOAP).

ниже уже упоминали Postman для тестирования именно HTTP API. Может, того курса будет достаточно, чтоб уложить в голове.

Спасибо большое!
Конечно, почитав ответы на свой вопрос, понял что затронул что-то широченное, на что нельзя ответить однозначно!
Благодарю за понимание!!

SOAP(outdated), REST(current standard in majority apps), GraphQL(new, being hyped up)

Є ще якісь варіанти?

серед generic-purpose протоколів ще є gRPC, а гугл каже про webhooks
але є ще спеціалізовані типу авторизаційних OAuth, saml, ldap

А ще буває АРІ взагалі напряму на НТТР базується(ну, коли навіть не прикидається REST, а просто рандомний набір енд поінтів та правил для параметрів).

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

звісно, все, що працює через НТТР можна тестувати тим самим постманом(навіть SOAP), але спеціалізовані інструменти можуть полегшувати процес. Також, в кожному протоколі є свій набір правил та логіки.

Не граю в розумника, скорше сам дивуюсь скільки там усього, якось раніше не замислювався

Не граю в розумника, скорше сам дивуюсь скільки там усього, якось раніше не замислювався

Та добре розписав!)

Я тут ще подумав про обмін даними по веб сокетам. Не знаю як воно правильно в архітектурі апу видається, як той інтерфейс звати.

Якщо говорити про основу, про реальні протоколи, а не цукор, то у вікі добре розписано: en.wikipedia.org/wiki/OSI_model

Я тут ще подумав про обмін даними по веб сокетам

Оооо, точно, вебсокети! Протокол поверх TCP, без залучення HTTP(погуглив, що там лиш для інішл підключення використовується НТТР). Не знаю, чи існують протоколи поверх вебсокетів, чи лиш унікальні для кожної системи API без жодної стандартизації. Але точно, що вебсокети — то ще окремий світ(до речі, не в курсі, чи то тестувати, хіба що браузерні плагіни під це)

Якщо говорити про основу, про реальні протоколи, а не цукор, то у вікі добре розписано: en.wikipedia.org/wiki/OSI_model

just in case, додам, що для новачка то вже точно перебор. Тестуванням бінарних протоколів поверх TCP або взагалі ARP — комусь то тре робити, але і вакансій небагато, і поріг входу ого-го.

Чисто для базового розуміння почитати цікаво. Воно як пиріг, і якщо не копати до деталізацій то щось та залишається. Але я схоже не зовсім коректний лінк скинув. Оце юзається а інеті:

en.m.wikipedia.org/...​i/Internet_protocol_suite

І починаючи з Transport layer йде вже конкретно те, що важливе для веб розробника. Ось наприклад абзац:

„For the purpose of providing process-specific transmission channels for applications, the layer establishes the concept of the network port. This is a numbered logical construct allocated specifically for each of the communication channels an application needs. For many types of services, these port numbers have been standardized so that client computers may address specific services of a server computer without the involvement service discovery or directory services.”

Приводить трохи до тями, а що то за номер після IP, чому він такий.

В універі якщо вчився по комп’ютерам напевно проходять цю базу) А хто там на конкретній спеціалізації не був, то щоб не бути равшаном, краще почитати.

OSI model описывает слои TCP\IP протокола, это напрямую не связано с сабжем, но для веб разработчика нужно, думаю. Если не с т.з. практической пользы, то для общего развития.
Касательно сокетов, это кмк не надо начинающему.

А что там такого сложного в сокетах? Открыл, послал, принял и пошел, закрыл. Чем работа с сокетами отличается от работы с файлами или другой подобной хренью?

И чё? Причем тут сокеты?
Или тебе волнует вопрос как юзать сокеты для многопоточности и распределенных вычислений?
Всё просто, в этом случае юзай их для посылки сообщения и приема их.

А что там такого сложного в сокетах? Открыл, послал, принял и пошел, закрыл.

c традиционным олдскульным TCP\IP сокетом — да.

Смотря насколько тцп/іп олдскульный :p

The first TCP implementations to handle congestion were described in 1984,[6] but Van Jacobson’s inclusion of an open source solution in the Berkeley Standard Distribution UNIX („BSD”) in 1988 first provided good behavior.
en.m.wikipedia.org/wiki/Network_congestion
Вопрос в потребности изучения для тестирования API, тут конечно мой промах в формулировке!(

Если вам нужно писать автотесты для API конкретного приложения или веб-ресурса, то обычно для этого есть специальная документация, написанная теми людьми, которые это API и разработали. И часто информация о документации находится на самом сайте в разделах API, for developers, documentation etc.

Якщо ти хочеш вивчити визначення АРІ, то

Аpplication programming interface (API) is a computing interface which defines interactions between multiple software intermediaries.

Якщо ти хочеш вивчити, як правильно створювати свій АРІ, тоді гугли :)

Это — жестоко, но направление задано верно ))

Это ты сам решил или начальник приказал?

Попробуйте другие слова из трёх букв, они тоже умные

Напевно ви мали на увазі ось цей процес?
habr.com/...​mpany/yandex/blog/499534

API это абстрактно набор неких функций. Вот только каких функций? Какого языка?

Користуватися АРІ чи робити свої АРІ?

потребность в изучении API,

Вопрос в потребности изучения для тестирования API, тут конечно мой промах в формулировке!(

Подписаться на комментарии