Урок за API за почивка: REST API архитектура и ограничения

rest api tutorial rest api architecture

В този урок ще научим за REST API, уеб услуги, архитектура на REST API, ограничения за REST API и как да тестваме API с помощта на POSTMAN:

Предварителни условия: Основни познания за уеб услугите.

Проверете тук за да получите ясно разбиране за уеб услугите.

Какво ще научите:

• Какво е REST API?
  • Разлика между САПУН И ПОЧИВКА
  • Защо да изберете ПОЧИВКА ЗА САПУН?
    • Защо пощальон?
  • REST API архитектура
  • REST API ограничения
  • Какво е POSTMAN?
  • Как да тествате API с пощальон?
    • Инсталация
• Заключение
  • Препоръчително четене

Какво е REST API?

API е просто интерфейс, който се използва от софтуерните компоненти за комуникация помежду си. Услугата е функция, която е добре дефинирана, самодостатъчна и не зависи от други услуги.

Уеб услугата е вид API, почти всички от тях работят през HTTP. Когато се разработи уеб API с помощта на REST Architecture, тогава той се нарича REST Web API.

Към момента има два вида уеб услуги,

• САПУН
• ПОЧИВКА

Разлика между САПУН И ПОЧИВКА

Защо да изберете ПОЧИВКА ЗА САПУН?

По-долу точките обясняват причините да изберете REST вместо SOAP.

• Много е добър за разработване и тестване на уеб API.
• REST изисква по-малка честотна лента.
• Можем да използваме AJAX за базирани на REST уеб API.
• Изисква по-малко синтактично анализиране.
• Размерът на полезния товар, създаден от JSON, е с по-малък размер.

В мрежата има много клиенти / инструменти, които ни позволяват да използваме RESTful уеб услуги.

Те са:

• Пощальон
• Разширен клиент за почивка
• DHC клиент за почивка
• Заявител
• Безсъние
• Утвърдимо
• Постер

Защо пощальон?

• Показва всички налични опции.
• Пощальонът има допълнителна функция (известна като Runner).
• Удобен потребителски интерфейс и лесен за използване.
• По-голяма група / членове на общността.

REST API архитектура

Това е главно архитектурата на мрежата в софтуерен архитектурен стил. Той е за разпределени хипермедийни системи. API RESTful директно се възползва от HTTP методологиите, определени от протокола RFC 2616.

Малко дефиниции

ПОЖАР означава интерфейс за програмиране на приложения. Това е набор от дефиниции на подпрограми, протоколи и инструменти за изграждане на приложен софтуер.

Уеб услуги са някои програмни кодове, които съдържат данни / вградени методи. Те се разгръщат от организацията през Интернет, за да комуникират с потребители, приложения на трети страни и др. За комуникация на съобщенията, предимно XML се използва като система за съобщения. XML просто кодира цялата комуникация между потребители и приложения.

HTTP означава Протокол за прехвърляне на хипертекст, използван от World Wide Web. Той определя как се форматират и предават съобщенията и какви действия предприемат уеб сървърите и браузърите в отговор на различни команди.

Архитектурен стил, те се характеризират с характеристиките, които се използват за създаване на структура и дори да я направят уникална. Стиловете са два вида: Многослоен и Унифициран интерфейс.

МРАЗА : Известен също като унифициран идентификатор на ресурс. Той идентифицира ресурс (текстов документ, файл с изображение и т.н.).
URL: Известен също като Унифициран локатор на ресурси. Това е подмножество на URI, което включва мрежово местоположение.
URN : Известно също като Унифицирано име на ресурс е подмножество на URI, които включват име в дадено пространство, но без местоположение.

Например,

http://elearning.com/amazon/restapi.html#books

Тук, в горния пример

МРАЗА : http://elearning.com/amazon/restapi.html#posts
URL : http://elearning.com/amazon/restapi.html
URN : elearning.com/amazon/restapi.html#posts

фаза на проектиране на жизнения цикъл на разработката на софтуер

Следователно URL адресът е URI, който идентифицира ресурс и също така предоставя средствата за намиране на ресурса, като описва начина за достъп до него.

Така че всеки URL може да бъде URI, но обратното не е вярно.

Услугата RESTful се излага чрез унифициран локатор на ресурси (URL). Това е логично име, което разделя идентичността на ресурса от това, което е прието или върнато.

Примерна REST архитектура:

REST API ограничения

Интерфейсът на API се казва RESTful, ако отговаря на следните ограничения:

• Унифициран интерфейс: Това означава, че независимо от всеки клиент, който използваме, основната концепция за внедряване и използване на REST услугите ще остане същата. Всички разработени REST API трябва да имат общ подход към разработването.
• Без гражданство: Това означава, че няма да се съхранява сесия. Така че сървърът няма да съхранява HTTP заявка, изпратена от клиент. Следователно за сървър всяка HTTP заявка е нова заявка. Без значение колко пъти е направена заявката или клиентът е уникален или не.
• Кешируемо: Кеширането означава колко често се осъществява достъп до данни и отговори от кеш вместо от сървъра. Концепцията за кеширане е приложима при изпращане на заявката на клиента. Така че подобрението на производителността се извършва от страна на клиента.
• Клиентски сървър: Сървърът и клиентите са независими един от друг по отношение на изпълнението. Клиентът трябва само да изпрати URI на заявката заедно с или без удостоверяване. След това сървърът прави останалата част от стъпката, което е отговор.
• Слоеста система: Клиентът може да изпрати само заявката до сървъра като URI на ресурса. Но след това, преди заявката да бъде изпратена до сървъра, съществува REST API, който ни предоставя слоестата системна архитектура. Това означава, че можем да разположим API на един сървър, данните да бъдат разположени на друг сървър и удостоверяване на друг сървър.
• Код при поискване (по избор): Понякога клиентът може да се нуждае от нещо повече от отговор. REST API ни позволява да изпратим изпълним код като отговор (този изпълним код може да бъде приспособление или всяка контрола). Не е задължително обаче дали сме активирали / внедрили тази функция.

Още няколко терминологии, свързани с Rest API:

Крайна точка : Това е препратката към URL адрес, който приема уеб заявки. Уеб услугата е адресируема с помощта на препратка към крайна точка.
Например, Http: // {Domain_URL} //librarygr/libraries.xml

Ресурси : Това е подмножество на Крайната точка. Обикновено крайните точки излагат някои обекти, които могат да се консумират чрез уеб услуги. Ресурсите са конкретно тази част от обект през URI на крайната точка.
Например, Http: // {Domain_URL} // api / pg_library / орнитология / лебед

Полезен товар : Полезният товар е информацията, която се изпраща при извършване на операция POST или PUT. Това са информацията, посочена в тялото на HTTP заявката.

Полезните товари се изпращат във формат JSON, Например,

Параметри :

Можем да предаваме параметри по два начина.

Параметри на заявката : Полезно за достъп до двойки ключ / стойност в низа на заявката на URL адреса (частта след?)

Най-добрият пример

http://jsonplaceholder.typicode.com/posts/?id=3

независими непредубедени отзиви за безплатна 64-битова защитна стена

Параметри на пътя: Полезно е да се съпостави част от URL адреса като параметър. Можем да изпратим информация като параметър на пътя по следния начин: Form-data, x-www-form-urlencoded, raw, binary.

Най-добрият пример:

https://api.github.com/gists/49b05378bb8920d5b4ec54efc27103e2/comments

Какво е POSTMAN?

POSTMAN е REST Client, просто приложение, което се доставя с браузъра Chrome. Той се разработва, като се имат предвид разработчиците, за да улеснят тестването на API повикванията. Той има собствен GUI за изпращане на заявките за API и четене на отговорите на API.

Можем да извършим тестването на REST API както ръчно, така и чрез автоматизация.

В следващия раздел ще научим как да тествате ръчно уеб API чрез POSTMAN клиент.

Как да тествате API с пощальон?

Инсталация

Трябва да имаме достъп до Уеб магазин на Chrome . В браузъра Chrome потърсете Postman. Щракнете тук за да го добавите към бутона Chrome.

След като бъде инсталиран успешно, можем да намерим POSTMAN под приложението Chrome. Просто щракнете върху иконата на пощальона, за да отворите POSTMAN. Ще отнеме време за стартиране за първи път.

Моля, направете справка със следния URL адрес, за да разберете как да използвате ПОЩАНТ като инструмент.

Предварителни условия: Интернет връзка е необходима за достъп до услуги, разположени в мрежата. В случай на достъп до услугите, разположени локално, уверете се, че са предоставени достатъчни права, привилегии на потребителя, който изпълнява тест чрез POSTMAN.

Umi ресурс URI: В този урок ще използваме фиктивен URI вместо истински URI. Ще ни даде отговорите по желание, но не могат да се правят промени на сървъра.

http://jsonplaceholder.typicode.com

Стъпки за навигация :

# 1) След като приложението POSTMAN бъде стартирано, можем да видим страницата Request по подразбиране.

# две) Можем да видим списъка с API повиквания, като щракнем върху падащото меню. Избирайки някоя от опциите от падащото меню, можем да поискаме API извикване към сървъра.

# 3) Щракнете върху бутона с променлива среда в горния десен ъгъл на ПОЩЕН. Задайте конкретната среда, където ще тестваме. Можем да го запазим за бъдещо изпълнение.

# 4) Запазената среда може да бъде достъпна от падащото меню Околна среда.

# 5) След това трябва да зададем URI на ресурса в даденото поле.

# 6) Щракнете върху бутона Params до полето Resource URI, за да зададете параметрите на заявката

# 7) Кликнете върху раздела Упълномощаване, изберете типа Разрешение от падащото меню и задайте желаното Разрешение или просто можете да го оставите като Без разрешение.

# 8) Кликнете върху раздела Заглавки и задайте необходимите заглавки като тип съдържание

# 9) Щракнете върху раздела Тяло, изберете радио бутона за данни за формуляра. Посочете необходимите параметри на тялото, които трябва да бъдат изпратени заедно с URL адреса на заявката

# 10) Щракнете върху раздела Body, изберете радио бутон x-www-form-urlencoded. Посочете необходимите параметри на тялото, които трябва да бъдат изпратени като кодирани, заедно с URL адреса на заявката

java създава масив от обекти

# единадесет) Кликнете върху раздела Body, изберете бутона за избор „raw“. Посочете необходимите параметри на тялото, които трябва да бъдат изпратени заедно с URL адреса на заявката. Това е в действителен JSON формат

# 12) Щракнете върху раздела Body, изберете бутона за избор „двоичен“. Посочете необходимите параметри на тялото (обикновено като файл), който трябва да бъде изпратен заедно с URL адреса на заявката.

# 13) След като конфигурирахме всички подробности, както е посочено по-горе, вече можем да „изпратим“ заявката. Също така можем да запишем заявката за изпращане като request.json (може да променим името на заявката).

# 14) Можем да видим списъка с направени заявки в левия страничен панел под раздела История.

# петнадесет) Също така можем да запазим всички подробности, свързани с заявката (URI, оторизация, параметри, тяло и т.н.) в съществуваща колекция или нова колекция. След като заявката бъде добавена към колекцията, ние можем да я експортираме (споделим) и дори да импортираме всяка съществуваща колекция.

Можем да споделяме Колекцията като връзка или като екипна библиотека чрез прост генериран код. Винаги можем да стартираме целия набор от колекции.

Дори можем да публикуваме URL адреса на колекцията в мрежата, така че всеки, който има достъп до публикувания URL адрес, да има достъп до колекцията и да използва услугите, предоставяни от Web API.

Има функция за влизане в POSTMAN, която ни позволява да съхраняваме историята, колекциите, данните за околната среда, локалното хранилище, така че да можем да ги запазим и да имаме достъп до тях навсякъде, по всяко време, след като сте влезли в POSTMAN.

Бегач

Използва се за стартиране на наличните ресурси в папката Collections.

Заключение

Повечето компании възприемат архитектурния стил REST за разработване / внедряване на уеб услуги, защото това е прост и лесен за използване интерфейс, който изисква по-малко обучение за съществуващите / новите членове на проекта. Организациите обмислят REST заедно със съществуващите си уеб услуги.

Прочетете също = >> Урок за API на Flask

В следващия урок, тази серия REST API, ще обсъдим различни видове кодове за отговор, типове REST заявки и т.н.

Препоръчително четене

• Кодове за отговор на API за почивка и типове заявки за почивка
• Урок за POSTMAN: Тестване на API с помощта на POSTMAN
• REST API Тестване с краставица, използвайки BDD подход
• 10 най-добри инструмента за тестване на API през 2021 г. (SOAP и REST API инструменти за тестване)
• REST API Тестване с Spring RestTemplate и TestNG
• Как да автоматизирам заявките за API с помощта на Rest Assured и Jenkins
• Как да създадете REST проект в SoapUI Pro: Урок # 13
• Урок за Parasoft SOAtest: Инструмент за тестване на API без скриптове