Основи на REST и RESTful API развитие

Уеб разработчиците често говорят за това REST принципи и RESTful архитектура на данни, тъй като това е важен аспект на съвременното развитие, но понякога може да бъде изключително объркващо. REST не е технология сама по себе си, а по-скоро метод за създаване на API с определени организационни принципи. Тези принципи са насоки за разработчиците и създаване на по-универсална среда за обработка на заявки за API.

В този пост бих искал да обясня RESTful практики за развитие от гледна точка на птичи поглед. Искам да се справя на Какво вместо как. Макар че ще се докосвам до двете области, тази публикация се прави за всеки, който се занимава с уеб разработка, но просто не може да разбере концепцията за REST API.

REST за уеб разработчици

Акронимът REST означава Представителен държавен трансфер. Това може да звучи донякъде объркващо, а влизането в уикито звучи още по-объркващо. Но е възможно да се опрости терминологията.

REST е само серия от насоки и архитектурни стилове, използвани за предаване на данни. Той обикновено се прилага за уеб приложения, но може да предава данни и на софтуер.

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

Комбинирайки всичко това заедно, RESTful API са API, които следват REST архитектурата.

Каква точно е REST архитектурата?

Тук е трудно да се определят особеностите. Въпреки това има някои архитектурни константи, като:

съгласуваност в целия API
Наличие на без гражданство, няма сесии от страна на сървъра
Използване на Кодове за състояние на HTTP където е уместно
Използване на Крайни точки за URL адреси с логическа йерархия
Версиите в URL адреса вместо в HTTP заглавки

Няма прекалено специфични насоки като спецификацията W3C HTML5, която може да доведе до объркване, и миазъм на несигурност по отношение на терминологията REST.

Също така, горният списък не трябва да се считат за твърди и бързи правила, въпреки че те се отнасят за най-модерните RESTful API.

ИЗОБРАЖЕНИЕ: restful-api-design.readthedocs.io

REST е a лека методология което го прави идеален за HTTP данни. Ето защо REST стана толкова популярен в интернет и защо се смята за най-добрия избор за развитие на API.

Както казва Виней Сани, “API е потребителски интерфейс на разработчика.” Всичко трябва да е лесно за използване и да осигурява чудесно потребителско изживяване. RESTful APIs правят точно това.

Ключови постъпки за API за RESTful

Тези съвети са в контекста на API строго за уеб приложения. Това означава, че HTTP е изискване, и често това означава API данните се хостват на външен сървър. Нека да разгледаме как работят API RESTful от страна на потребителя на API.

Потребителят на API е уеб разработчикът, който може да създаде скрипт, който се свързва с външен API сървър, след което необходимите данни се предават през HTTP. След това разработчикът може да показва данни на уебсайта си без личен достъп до външния сървър (като изтегляне на данни от Twitter).

Като цяло има четири команди използван за достъп до RESTful API:

GET за извличане на обект
POST за създаване на нов обект
СЛАГАМ за промяна или замяна на обект
ИЗТРИЙ за отстраняване на обект

Всеки един от тези методи трябва да бъде преминали с извикването на API да каже на сървъра какво да прави.

По-голямата част от уеб API само разреши GET искания за изтегляне на данни от външен сървър. Удостоверяването не е задължително, но със сигурност е добра идея, когато се допускат потенциално опасни команди СЛАГАМ или ИЗТРИЙ.

Въпреки това не много RESTful API дори отиват толкова далеч. Помислете за Pokéapi, която е безплатна база данни на API за Pokémon. Тя е отворена за обществеността с приличен лимит (ограничаване на потребителите до определен брой API заявки за определен период от време), но само позволява GET метод за достъп до ресурси. Това може да бъде разговорно наречено a API само за потребление.

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

RESTful APIs използват съществителни за API обекти, и глаголи за извършване на действия върху тези обекти. Удостоверяването може да бъде част от това, ограничаването на скоростта може също да бъде част от това. Но един много прост API може да се справи без особена грижа към ограниченията на потребителите.

Достъп до ресурсите на API

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

Някои URL адреси могат да включват префикс директория / V2 / за актуализирана версия 2 на предишен API. Това е обичайно за разработчиците, които не искат да амортизират своя 1.x API, но все пак искат да предложат най-новата структура.

Наистина ми хареса това пост покритие основни URL структури и примери от други услуги.

Имайте предвид, че крайната точка данните за връщане ще се променят драматично базиран на HTTP метод. Например, GET извлича съдържание, докато POST създава ново съдържание. Искането може да сочи към същата крайна точка, но резултатът може да бъде много различен.

Разглеждането на примери онлайн може да ви помогне да разберете по-ясно понятията. Вече видяхме Pokeapi, но ето и някои други примери от реалния свят да прочетете:

API на Reddit
GitHub API
API на Flickr
Pinterest API

Изграждане на собствен API

Процесът на изграждане на собствен API не трябва да се приема леко, но също така не е толкова сложно, колкото си мислите. Това отнема разбиране на моделите за проектиране на API и най-добрите практики да се изгради нещо от реална стойност.

Всеки API трябва свържете с вашия сървър да върне данни от някакъв вид. Не само трябва да напишете код, за да го направите, но също така трябва да форматирате връщаните данни. Други потенциални изисквания включват заверка и ограничаване на скоростта, така че изграждането на API със сигурност не е за хора със слаби сърца.

Но нека погледнем някои основни принципи на API архитектурата.

Изграждане на крайни точки

Един аспект на развитието на API е крайни точки на сградата. Кога създаване на ресурси искате да използвате съществителни, а не глаголи. Това означава, че данните в API трябва да връщат човек, място или нещо, най-често това е нещо със специфични атрибути (например чуруликане и всички метаданни).

Може да се окаже трудно да се научи да се наричат имена, но това е решаващ аспект от развитието на API. Опростяването е най-доброто, когато е възможно.

Голям дебат е единично срещу множествено число съществителни. Ако сте създавали приложен програмен интерфейс (Twitter API), може първо да имате групата на обектите (т.е. чуруликане), след това втората позиция на обекта (т. Нар. Twitter).

 $ / tweet / 15032934882934 $ / туитове / 15032934882934

В този случай бих казал, че формата в единствено число изглежда по-добре. Това е вярно, особено когато се връща само един ресурс. Но няма документиран 100% верен отговор, така че правете най-доброто за вашия проект.

Задайте тип на връщане

Друго съображение е тип данни за връщане. Повечето уеб потребители очакват JSON съдържание, така че вероятно това е най-добрият вариант. XML е друг избор, ако искате да предложите и двете. Въпреки това JSON е основният тип връщане на API сред уеб разработчиците.

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

Ако току-що започнете, моля, помислете как да ги премахнете:

Сайт за обучение на REST API
Писане на прост REST API
Изграждане на уеб услуга RESTful

Допълнителни ресурси

Най-добрият начин да научите развитието на уеб приложения е чрез практика. Предоставената теория винаги си струва да се изучава, защото ви позволява да разговаряте с разработчиците и да разберете как работят нещата.

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

Ако това е вашата цел, моля, помислете за следните ресурси, за да подпомогнете пътуването ви.

Книги

Правилник за проектиране на REST API
RESTful уеб API
RESTful Готварска книга за уеб услуги
Непроменен отдих: Ръководство за проектиране на Perfect API

статии

Ръководство за начинаещи за HTTP и REST
Създаване на RESTful API
RESTful Ръководство за именуване на ресурси
Създаване на REST API с помощта на MEAN Stack