Съдържание[Крия][Покажи]
- 1. Какво разбирате под REST?
- 2. Какво имате предвид под REST API?
- 3. Какво точно е URI?
- 4. Какви са характеристиките на RESTful Web Services?
- 5. Какви са водещите принципи на REST?
- 6. Споменете HTTP методите, които REST поддържа.
- 7. Опишете ограниченията, поставени от последователен интерфейс.
- 8. Какво точно е REST ресурс?
- 9. Какво означава JAX-RS за вас?
- 10. Какво отличава AJAX и REST един от друг?
- 11. Можете ли да изброите някои недостатъци на уеб услугите на RESTful?
- 12. Какво отличава техниките PUT и POST една от друга?
- 13. Как тествате RESTful уеб услуги?
- 14. Опишете REST API в реалния свят.
- 15. Как работи архитектурата на микросервизите?
- 16. Какво точно е кеширането?
- 17. Опишете полезния товар.
- 18. Правете разлика между SOAP и REST?
- 19. Може ли протоколът за сигурност на транспортния слой (TLS) да се използва с REST?
- 20. Идемпотентни методи: какви са те? Как се прилага в света на RESTful уеб услугите?
- 21. Каква е функционалността на HTTP Basic Authentication?
- 22. Мислите ли, че GraphQL е най-добрият избор за създаване на архитектура на микросервизи?
- 23. Какви са основните разлики между безопасните и идемпотентните HTTP методи?
- 24. Какво означава JAX-RS API от RESTful Root Resource Classes?
- 25. Какво точно е Postman и защо се използва?
- 26. Как се защитават REST API?
- Заключение
Еволюцията на REST направи API невероятно достъпни, като същевременно разкри пълната им сила и потенциал. REST API са лесни за създаване и кеширане поради тяхната ориентирана към ресурсите архитектура.
Освен това през цялото време RESTful API бяха предшествениците на други значими разработки като облачни изчисления и дизайн, базиран на микроуслуги.
Следователно не трябва да е изненада, че разработчиците на REST API са търсени днес, като се има предвид как предоставят конкурентно предимство на фирмите, които използват RESTful услуги. REST API са популярна тенденция в дизайна.
Много ИТ фирми искат познания за REST API софтуерни разработчици и попитайте за това в технически интервюта.
Ето някои от най-типичните въпроси за интервю за REST API, които ще ви помогнат да сте готови за интервюта в различни фирми, ако искате да работите в областта на разработката на REST API.
1. Какво разбирате под REST?
REST е архитектурна парадигма за проектиране на уеб-базирани приложения, които са базирани на Hypertext Transfer Protocol (HTTP).
REST определя определени стандарти, на които уеб услугите трябва да отговарят, за да се считат за RESTful. Тези препоръки гарантират, че заявките и ресурсите се предават бързо и ефективно между клиент и сървър чрез стандартизирани HTTP протоколи.
2. Какво имате предвид под REST API?
Връзка софтуер към софтуер, известна като интерфейс за програмиране на приложения, позволява комуникация и споделяне на данни между иначе независими програми. Например, уебсайт за новини може да използва API на Twitter, за да открива автоматично подходящи туитове и да ги интегрира в новинарски истории.
API, който се придържа към принципите на REST, е известен като REST API, понякога известен като RESTful API. В REST API всяка част от данните се обработва като ресурс и се дава отделна стандартна идентичност на ресурса (URI).
Например API на Twitter прави всеки туит ресурс, който може да се извлече и е достъпен за клиентите. API на Twitter може да се използва от потребителите за публикуване на туитове и изпълнение на други задачи на уебсайта.
3. Какво точно е URI?
A компютърна мрежа ресурсът може да бъде препратен с помощта на URI или унифициран идентификатор на ресурс. Той служи като средство за отделяне на един ресурс от друг. Източниците може или не могат да бъдат онлайн.
Благодарение на стандартната си структура URI адресите улесняват свързването дори с различни видове ресурси. Местоположението или името на ресурса е включено в URI заедно с низ от знаци.
URI се състои от път, схема, заявка и други елементи, но не включва протокола.
Използвайки протокол, URL адресите (Uniform Resource Locators) се използват за намиране на ресурси в интернет или достъпни чрез него.
4. Какви са характеристиките на RESTful Web Services?
- Парадигмата клиент-сървър е в основата на услугата.
- Услугата може да осъществява достъп до ресурси чрез използване на URI.
- Услугата използва HTTP протокола за получаване на данни/ресурси, изпълнение на заявки и изпълнение на други задачи.
- Съобщенията са името на метода, използван за комуникация между клиента и сървъра.
- Тези услуги могат също така да реализират REST архитектурния модел, използвайки SOAP услуги.
- За да се намалят обажданията на сървъра за един и същ вид повтарящи се заявки, тези услуги също използват идеята за кеширане.
5. Какви са водещите принципи на REST?
Пет критерия трябва да бъдат изпълнени от REST API:
Отделяне на клиент-сървър: Само поредица от заявки и отговори могат да се използват за комуникация между клиента и сървъра. Само клиентите и сървърите могат съответно да изпращат заявки и отговори. Тази ясна идея позволява и на двете страни да функционират независимо една от друга.
Единен интерфейс: Трябва да има единен протокол за всички връзки клиент-сървър. Този протокол за REST е HTTP. Тъй като всяко приложение иска и изпраща данни, използвайки един и същ език, последователният интерфейс прави интеграциите по-лесни.
Без състояние: Сървърът не записва никакви записи на предишни заявки или отговори при комуникация без състояние. Всяка заявка и отговор предоставят всички подробности, необходими за завършване на обмена. Комуникацията без състояние подобрява скоростта, спестява памет и намалява напрежението върху сървъра. Освен това се избягва потенциалът от неуспех на заявка поради непълни данни.
Многослойна система: Сървърите, които се намират между клиента и API сървъра, се наричат слоеве. Тези допълнителни сървъри изпълняват различни услуги, като откриване на спам и оптимизиране на скоростта. Слоевете в REST са модулни, което означава, че могат да се добавят и изтриват, без да се засяга комуникацията между клиента и API сървъра.
Кеширане: Клиентите могат да кешират всякакви ресурси, за да увеличат скоростта, ако отговорите на сървъра показват дали ресурсът може да се кешира или не.
Кодиране при поискване: В отговор API може да предава изпълним компютърен код на клиентите. След това клиентското приложение може да изпълни кода на своя собствена задна част.
6. Споменете HTTP методите, които REST поддържа.
HTTP методите, които REST поддържа, са:
- GET: Този метод изисква ресурс на посочения URL адрес. Основният текст на заявката не трябва да се включва, защото ще бъде игнориран. Може да е възможно да го кеширате локално или на сървъра.
- POST: Този метод изпраща данни към услуга за обработка и услугата обикновено трябва да върне нов или променен ресурс.
- PUT: Ресурсът се актуализира на URL адреса на заявката.
- ИЗТРИВАНЕ: Ресурсът се изтрива на URL адреса на заявката.
- Опции: Идентифицира поддържаните методи.
- HEAD: Връщат се метаданните на URL адреса на заявката.
7. Опишете ограниченията, поставени от последователен интерфейс.
За да се отдели клиентът от сървъра, е необходим последователен интерфейс.
За да се постигне последователен интерфейс, са необходими следните четири ограничения:
- Идентификация на ресурси: Клиентските заявки трябва да използват стандартни идентификатори на ресурси за идентифициране на ресурси (URI)
- Манипулиране на ресурс с помощта на тези представяния: Клиентите разполагат с цялата необходима информация, за да могат да променят състоянието на ресурса, когато получат представяне на ресурс от сървъра.
- Самоописателни съобщения: Съобщенията включват всички метаданни и друга информация, необходима на получателя, за да ги разбере.
- Хипермедия като двигател на състоянието на приложението: Каналът за комуникация клиент-сървър е хипермедия, като HTML, и клиентите не се нуждаят от специфична за API документация, за да разберат отговорите на сървъра.
8. Какво точно е REST ресурс?
Ресурсите са основните компоненти на RESTful уеб услуга в REST архитектура. Те включват цялата важна информация, до която клиентът на API трябва да има достъп.
Всеки тип ресурси, като HTML страница, изображение, видео или всичко друго, необходимо за API дейност, може да бъде достъпен през сървъра в система клиент-сървър.
Ресурсите се идентифицират чрез унифициран идентификатор на ресурс. Текст, JSON или XML са приемливи представяния на ресурси. Като се има предвид това, няма ограничения за формата на представянето.
9. Какво означава JAX-RS за вас?
По-лесно е да създавате RESTful уеб услуги в Java благодарение на Java API за RESTful уеб услуги, често известен като JAX-RS. Разработчиците могат да опишат ресурсите и операциите, които могат да бъдат извършени върху тях, като използват предоставените анотации.
10. Какво отличава AJAX и REST един от друг?
Аякс:
- Ajax е група от технологии, които позволяват динамично актуализиране на потребителски интерфейс елементи, без да се налага да презареждате страницата.
- Ajax премахва асинхронната комуникация между клиента и сървъра.
ПОЧИВКА:
- REST изисква комуникация между сървъра и клиента.
- Използването на ресурси е важно за URL структурата и модела на заявка/отговор, използвани от REST.
11. Можете ли да изброите някои недостатъци на уеб услугите на RESTful?
Сесиите не могат да бъдат поддържани, тъй като услугите се придържат към идеята за лица без гражданство. (Клиентът е отговорен за предаването на идентификатора на сесията през цялата симулация на сесията.)
Ограниченията на сигурността не са основни за REST. Протоколите, които го използват, наследяват предпазните мерки за сигурност. Ето защо е важно да се внимава при въвеждането на мерки за сигурност, като например интегриране на базирани на SSL/TLS удостоверявания.
12. Какво отличава техниките PUT и POST една от друга?
СЛАГАМ:
- Няма кеш за PUT отговори.
- Идемпотентност (т.е. множество заявки ще дадат един и същ резултат)
- полезният товар на заявката актуализира или заменя целевия ресурс.
POST:
- idempotent not (т.е. множество заявки ще дадат множество от един и същ ресурс)
- Уеб сървърът обработва полезния товар на заявката въз основа на предвидения ресурс.
- Ако е включена подходящата заглавка за контрол на кеша, POST отговорите могат да бъдат кеширани.
13. Как тествате RESTful уеб услуги?
Тестването на уеб услуги RESTful може да бъде подпомогнато от редица инструменти, включително Swagger и Postman. Проверката на параметри на заявка като параметри на заявка, заглавки и заглавки на отговор е възможна благодарение на изобилието от функции на последните.
Postman може да се използва за отправяне на заявки до крайни точки и показване на резултатите. И XML и JSON могат да бъдат създадени от тези отговори.
Postman и Swagger предоставят изключително сравними функции. От друга страна, Swagger също предлага възможности като документация за крайни точки.
14. Опишете REST API в реалния свят.
- Уебсайтовете за пътуване и продажба на билети могат да се възползват от времето на полетите и цените, които авиокомпаниите предоставят чрез API.
- За да могат приложенията за картографиране и навигация (като Google Maps) да ги използват, агенциите за обществен транспорт често правят своите данни публично достъпни в реално време чрез API.
- Приложенията за времето използват отворени API, които обменят данни за времето, за да показват информация за времето.
- Разработчиците имат достъп до картографските данни на Google Maps чрез редица хоствани API. Тези API се използват от разработчиците за вграждане на динамични карти в техните приложения и уебсайтове.
15. Как работи архитектурата на микросервизите?
- Заявките се изпращат от различни клиенти, използващи различни устройства.
- След потвърждаване на самоличността на клиентите, доставчиците на идентичност предоставят токени за сигурност.
- Клиентските заявки се управляват от API Gateway.
- Целият материал на системата се запазва като статично съдържание.
- Инструментът за управление проверява баланса на услугите на възлите и всички грешки.
- Откриването на пътя на комуникация между микроуслугите се подпомага от откриването на услуги.
- Центровете за данни и прокси сървърите съставляват разпръснати мрежови системи, наречени мрежи за доставка на съдържание.
- Дистанционните услуги осигуряват достъп до информация от разстояние.
16. Какво точно е кеширането?
Практиката за временно съхраняване на копие на сървърен отговор някъде (като паметта на компютъра) с цел по-бърз достъп до него по-късно е известна като кеширане.
Кеширането подобрява скоростта на сървъра при използване на REST API, като намалява количеството работа, което сървърът трябва да извърши, за да удовлетвори заявката. Приложенията, които използват API, работят по-бързо благодарение на кеширането, защото не се налага да изпращат нова заявка всеки път, когато имат нужда от ресурс.
Полето Cache-Control на заглавката на HTTP отговора съдържа информация за това колко време даден ресурс може да бъде кеширан от клиента, преди да има нужда от нов достъп.
17. Опишете полезния товар.
Полезният товар в REST се отнася до информацията, съдържаща се в тялото на HTTP отговора. Клиентът използва техниката GET, за да поиска въпросните данни.
Документът, съдържащ текста на туита и всички необходими файлове за поставяне на туита на уебсайт, ще бъде включен в полезния товар, например, ако поискате от API на Twitter конкретен туит. Освен това полезният товар може да бъде включен в HTTP заявката чрез метода POST.
18. Разграничете SOAP срещу REST?
- За разлика от SOAP, който може да обработва само XML, REST позволява по-широка гама от формати на ресурси, включително XML, текст, HTML, снимки, видео и др.
- Когато сигурността е от решаващо значение за онлайн приложенията, SOAP е полезен. REST не може да се използва, когато транзакциите трябва да бъдат изпълнени сигурно, тъй като не е особено сигурен.
- Тъй като SOAP е само протокол, REST може да го използва в своите уеб услуги, но не и обратното.
- Докато REST е само архитектурен модел, използван за разработване на уеб услуги и спазва определени ограничения като настройка клиент-сървър, липса на състояние, отговор с възможност за кеширане, многослойни системи и последователен интерфейс, SOAP е протокол, който работи на определени стандарти, които трябва да се спазват стриктно да се.
- Докато REST използва универсални идентификатори на ресурси (URI), SOAP използва сервизни интерфейси, за да предостави своите възможности на клиентските приложения. REST има по-ниска нужда от честотна лента от SOAP, тъй като SOAP съобщенията са по-натоварени с информация.
19. Може ли протоколът за сигурност на транспортния слой (TLS) да се използва с REST?
Всъщност можем. Комуникацията на REST клиента и сървъра е криптирана чрез TLS, а протоколът също така дава на клиентите начин за удостоверяване на сървъри.
Поради факта, че е заместител на Secure Socket Layer, той се използва за защитена комуникация (SSL). Внедряването на RESTful уеб услуги е успешно с HTTPS, защото си сътрудничи ефективно както с TLS, така и с SSL.
REST наследява характеристиките на протокола, който прилага, което е едно нещо, което трябва да се отбележи тук. В резултат на това защитата на сигурността зависи от протокола, който REST използва.
20. Идемпотентни методи: какви са те? Как се прилага в света на RESTful уеб услугите?
Когато URI е един и същ, някои HTTP методи в заявка имат същото въздействие върху сървъра, независимо дали са доставени веднъж или няколко пъти. Идемпотентните техники са това, което са известни като.
Например, без значение колко пъти се изпълнява URI, използващ метода GET, сървърът винаги ще получава същия резултат. Идемпотентните методи включват GET, PUT и PATCH, за да назовем само няколко.
Идемпотентните HTTP методи са някои от използваните от RESTful уеб приложения. Те са необходими, за да се гарантира последователност в дейностите на RESTful уеб услугите.
Клиентите, които използват REST API, могат да направят грешки в кода, които принуждават REST API да прави случайно повтарящи се заявки. Тези обаждания имат потенциал за злоупотреба с ресурси.
21. Каква е функционалността на HTTP Basic Authentication?
Когато използва основно удостоверяване като част от API, потребителят трябва да изпрати потребителското име и паролата, които са свързани от браузъра във формата „потребителско име: парола“ и са кодирани base64.
При всяка HTTP заявка от браузъра кодираната стойност се доставя като стойност за заглавката „Упълномощаване“. Тъй като идентификационните данни са просто кодирани, препоръчително е да използвате този формуляр, когато изпращате HTTPS заявки, тъй като те не са защитени и могат да бъдат прихванати от всеки, ако не се използват протоколи за сигурност.
22. Мислите ли, че GraphQL е най-добрият избор за създаване на архитектура на микросервизи?
Микроуслугите и GraphQL вървят перфектно, защото GraphQL пази вашата архитектура на микроуслуги в тайна от вашите клиенти.
От предния край искате всичките ви данни да идват от един API, докато от задния край искате да ги разделите на микроуслуги. Най-добрата техника, за която знам, за да постигна и двете, е използването на GraphQL.
Той ви позволява да разделите своя бекенд на микроуслуги, като същевременно предоставяте на всяко приложение единичен API и позволявате обединяване на данни от различни услуги.
23. Какви са основните разлики между безопасните и идемпотентните HTTP методи?
Идемпотентните методи дават същия резултат, когато се извикват веднъж или няколко пъти чрез една и съща заявка. Методът PUT е идемпотентен.
Всички безопасни начини са идемпотентни, но не всички идемпотентни методи са безопасни, тъй като безопасните методи не променят ресурсите. Например GET е защитен, тъй като просто извлича данни и не променя ресурса.
Освен това, той е идемпотентен, което означава, че винаги ще връща един и същ отговор, когато бъде извикан.
24. Какво означава JAX-RS API от RESTful Root Resource Classes?
Java Enterprise Edition предоставя класове и интерфейси, които се придържат към изискванията на JAX-RS API. С помощта на JAX-RS създаването на уеб услуги на Java в архитектурен стил REST става по-лесно.
В JAX-RS API класовете на коренните ресурси са просто „обикновени стари Java обекти“ или POJO. За да внедрят необходимите уеб ресурси, те използват JAX-RS анотации.
Те или имат @path анотации, или поне един от техните методи има @path анотации. Те могат да бъдат обобщени като Java класове с методи за работа с крайни точки на API.
25. Какво точно е Postman и защо се използва?
Инструмент за разработка на API, наречен Postman, се използва за създаване, тестване и модифициране на API. Този инструмент може да се използва от разработчиците за всяка функция, която изискват за API. Опростява и улеснява работата на разработчиците.
Postman улеснява извършването на различни HTTP заявки, включително GET, POST, PUT и PATCH, запазване на среди за по-късна употреба и преобразуване на API в код на редица различни езици.
Всеки етап от цикъла на API е улеснен с Postman и сътрудничеството е рационализирано за по-бързо разработване на API.
Освен това, той позволява на разработчиците да управляват документацията, спецификациите, тестовите случаи, процесите и каталозите на API.
26. Как се защитават REST API?
Тъй като REST API не използват толкова строги предпазни мерки за сигурност като SOAP API, чувствителните данни не трябва да се изпращат или извличат с тях.
Но надеждните REST API продължават да интегрират контроли за сигурност за безопасно и надеждно предаване на данни.
- Удостоверяване и оторизация: Всяка заявка, направена към API, трябва да премине тези две проверки. Потвърждаването на самоличността на клиента чрез удостоверяване и потвърждаването, че имат правомощия за достъп до исканите ресурси чрез оторизация са два различни процеса.
- Валидиране: Преди API да предостави достъп до своите ресурси, заявките трябва да бъдат проверени за евентуално опасен код след удостоверяване и оторизация. По този начин сървърът ще бъде отворен за атака чрез инжектиране.
- Валидиране: Преди API да предостави достъп до своите ресурси, заявките трябва да бъдат проверени за евентуално опасен код след удостоверяване и оторизация. По този начин сървърът ще бъде отворен за атака чрез инжектиране.
- Криптиране: TLS/SSL криптирането защитава връзката между клиента и сървъра и предпазва хакерите от прихващане на заявки и отговори.
- Техниките за ограничаване на скоростта, като ограничения и дроселиране, защитават сървърите от атаки с груба сила като DDoS, които имат за цел да ги влошат или сринат.
- Без чувствителна информация в URI: URI адресите на ресурсите не трябва да съдържат никакви защитени данни (като потребителско име, парола или токен за удостоверяване).
Заключение
Честито! Няколко основни до сложни въпроса за интервю с REST API и съответните им решения вече са на една ръка разстояние.
Сега, след като имате добра представа как да отговаряте на някои от типичните въпроси за интервю за REST API, можете да продължите да отговаряте на интервютата. Следващата стъпка зависи от вашите цели.
посещение Интервюта с Hashdork, за да се подготвите за интервюта.
Оставете коментар