Змест[Схаваць][Паказаць]
- 1. Што вы разумееце пад REST?
- 2. Што вы маеце на ўвазе пад REST API?
- 3. Што такое URI?
- 4. Якія характарыстыкі вэб-сэрвісаў RESTful?
- 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?
- 22. Як вы лічыце, ці з'яўляецца GraphQL лепшым выбарам для стварэння архітэктуры мікрасэрвісаў?
- 23. Якія асноўныя адрозненні паміж бяспечнымі і ідэмпатыўнымі метадамі HTTP?
- 24. Што азначае API JAX-RS пад класамі каранёвых рэсурсаў RESTful?
- 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 - гэта архітэктурная парадыгма для распрацоўкі вэб-прыкладанняў, заснаваных на пратаколе перадачы гіпертэксту (HTTP).
REST вызначае пэўныя стандарты, якім вэб-сэрвісы павінны адпавядаць, каб лічыцца RESTful. Гэтыя рэкамендацыі гарантуюць, што запыты і рэсурсы перадаюцца хутка і эфектыўна паміж кліентам і серверам з выкарыстаннем стандартызаваных пратаколаў HTTP.
2. Што вы маеце на ўвазе пад REST API?
Спасылка паміж праграмным забеспячэннем, вядомая як інтэрфейс прыкладнога праграмавання, забяспечвае сувязь і абмен дадзенымі паміж незалежнымі праграмамі. Напрыклад, навінавы вэб-сайт можа выкарыстоўваць Twitter API для аўтаматычнага выяўлення адпаведных твітаў і інтэграцыі іх у навіны.
API, які прытрымліваецца прынцыпаў REST, вядомы як REST API, часам вядомы як RESTful API. У REST API кожная частка даных апрацоўваецца як рэсурс і атрымлівае асобны стандартны ідэнтыфікатар рэсурсу (URI).
Напрыклад, Twitter API робіць кожны твіт рэсурсам, даступным для кліентаў. Twitter API можа выкарыстоўвацца карыстальнікамі для публікацыі твітаў і выканання іншых задач вэб-сайта.
3. Што такое URI?
A кампутарная сетка рэсурс можна спасылацца з дапамогай URI або ўніфікаванага ідэнтыфікатара рэсурсу. Ён служыць сродкам аддзялення аднаго рэсурсу ад іншага. Крыніцы могуць быць або не быць у інтэрнэце.
Дзякуючы сваёй стандартнай структуры URI спрашчаюць падключэнне нават да розных тыпаў рэсурсаў. Размяшчэнне або назва рэсурсу ўключана ў URI разам з радком сімвалаў.
URI складаецца з шляху, схемы, запыту і іншых элементаў, але не ўключае пратакол.
Выкарыстоўваючы пратакол, URL (Uniform Resource Locators) выкарыстоўваюцца для пошуку рэсурсаў у Інтэрнэце або даступных праз яго.
4. Якія характарыстыкі вэб-сэрвісаў RESTful?
- Парадыгма кліент-сервер - гэта аснова сэрвісу.
- Сэрвіс можа атрымліваць доступ да рэсурсаў з дапамогай URI.
- Служба выкарыстоўвае пратакол HTTP для атрымання даных/рэсурсаў, выканання запытаў і выканання іншых задач.
- Абмен паведамленнямі - гэта назва метаду, які выкарыстоўваецца для сувязі паміж кліентам і серверам.
- Гэтыя сэрвісы таксама могуць рэалізаваць архітэктурны шаблон REST з дапамогай сэрвісаў SOAP.
- Каб скараціць колькасць выклікаў сервера для аднатыпных паўтаральных запытаў, гэтыя службы таксама выкарыстоўваюць ідэю кэшавання.
5. Якія кіруючыя прынцыпы REST?
API REST павінны адпавядаць пяці крытэрам:
Развязка кліент-сервер: для сувязі паміж кліентам і серверам можа выкарыстоўвацца толькі серыя запытаў і адказаў. Толькі кліенты і серверы могуць адпраўляць запыты і адказы адпаведна. Гэтая простая ідэя дазваляе абодвум бакам працаваць незалежна адзін ад аднаго.
Адзіны інтэрфейс: павінен быць адзіны пратакол для ўсіх злучэнняў кліент-сервер. Гэты пратакол для 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.
- Idempotent (г.зн. некалькі запытаў дадуць аднолькавы вынік)
- карысная нагрузка запыту абнаўляе або замяняе мэтавы рэсурс.
POST:
- idempotent not (г.зн. некалькі запытаў дадуць некалькі рэсурсаў)
- Вэб-сервер апрацоўвае карысную нагрузку запыту на аснове меркаванага рэсурсу.
- Калі ўключаны адпаведны загаловак кіравання кэшам, адказы POST могуць захоўвацца ў кэшы.
13. Як вы тэстуеце вэб-службы RESTful?
Тэставанне вэб-сэрвісаў RESTful можа ажыццяўляцца з дапамогай шэрагу інструментаў, у тым ліку Swagger і 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, і пратакол таксама дае кліентам магчымасць аўтэнтыфікацыі сервераў.
У сувязі з тым, што гэта замена ўзроўню абароненых сокетаў, ён выкарыстоўваецца для бяспечнай сувязі (SSL). Рэалізацыя вэб-сэрвісаў RESTful паспяховая з HTTPS, таму што ён эфектыўна супрацоўнічае з TLS і SSL.
REST успадкоўвае характарыстыкі пратакола, які ён рэалізуе, што тут варта адзначыць. У выніку абарона бяспекі залежыць ад пратаколу, які выкарыстоўвае REST.
20. Ідэмпатыўныя метады: што гэта такое? Як гэта прымяняецца да свету вэб-сэрвісаў RESTful?
Калі URI аднолькавы, некаторыя метады HTTP у запыце аднолькава ўплываюць на сервер незалежна ад таго, дастаўляюцца яны адзін ці некалькі разоў. Ідэмпатытныя метады - гэта тое, што яны вядомыя.
Напрыклад, незалежна ад таго, колькі разоў запускаецца URI з выкарыстаннем метаду GET, сервер заўсёды будзе атрымліваць аднолькавы вынік. Idempotent метады ўключаюць у сябе GET, PUT і PATCH, каб назваць некалькі.
Idempotent метады HTTP некаторыя з тых, якія выкарыстоўваюцца RESTful вэб-прыкладання. Яны неабходны для забеспячэння ўзгодненасці ў дзейнасці вэб-сэрвісаў RESTful.
Кліенты, якія выкарыстоўваюць REST API, могуць рабіць памылкі ў кодзе, якія прымушаюць REST API рабіць выпадкова паўторныя запыты. Гэтыя званкі могуць злоўжываць рэсурсамі.
21. Што такое функцыянальнасць базавай аўтэнтыфікацыі HTTP?
Пры выкарыстанні базавай аўтэнтыфікацыі як часткі API, карыстальнік павінен адправіць імя карыстальніка і пароль, якія аб'ядноўваюцца браўзерам у форме «імя карыстальніка: пароль» і закадаваны ў base64.
Пры кожным HTTP-запыте з браўзера закадаванае значэнне дастаўляецца як значэнне для загалоўка «Аўтарызацыя». Паколькі ўліковыя дадзеныя проста закадзіраваны, рэкамендуецца выкарыстоўваць гэту форму пры адпраўцы запытаў HTTPS, таму што яны не з'яўляюцца бяспечнымі і могуць быць перахоплены кім-небудзь, калі не выкарыстоўваюцца пратаколы бяспекі.
22. Як вы лічыце, ці з'яўляецца GraphQL лепшым выбарам для стварэння архітэктуры мікрасэрвісаў?
Мікрасэрвісы і GraphQL выдатна спалучаюцца, таму што GraphQL захоўвае вашу архітэктуру мікрасэрвісаў у сакрэце ад вашых кліентаў.
З інтэрфейсу вы хочаце, каб усе вашы даныя паступалі з аднаго API, а з боку ззаду вы хочаце падзяліць іх на мікрасэрвісы. Найлепшы метад, які я ведаю, каб дасягнуць абодвух, - гэта выкарыстанне GraphQL.
Гэта дазваляе вам падзяліць бэкэнд на мікрасэрвісы, пры гэтым даючы кожнаму дадатку адзіны API і дазваляючы аб'ядноўваць дадзеныя з розных сэрвісаў.
23. Якія асноўныя адрозненні паміж бяспечнымі і ідэмпатыўнымі метадамі HTTP?
Ідэмпэнтныя метады даюць аднолькавы вынік, калі іх выклікаць адзін ці некалькі разоў праз адзін і той жа запыт. Метад PUT з'яўляецца ідэмпатытным.
Усе бяспечныя спосабы ідэмпатытныя, але не ўсе ідэмпатынтныя метады бяспечныя, бо бяспечныя метады не змяняюць рэсурсы. Напрыклад, GET бяспечны, бо ён проста здабывае даныя і не змяняе рэсурс.
Акрамя таго, ён ідэмпотэнтны, што азначае, што ён заўсёды будзе вяртаць адзін і той жа адказ пры выкліку.
24. Што азначае API JAX-RS пад класамі каранёвых рэсурсаў RESTful?
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 захоўваюцца ў бяспецы?
Паколькі API-інтэрфейсы REST не выкарыстоўваюць такія строгія меры бяспекі, як API-інтэрфейсы SOAP, канфідэнцыяльныя даныя не павінны адпраўляцца або здабывацца з іх дапамогай.
Тым не менш, вартыя даверу REST API працягваюць інтэграваць кантроль бяспекі для бяспечнай і надзейнай перадачы даных.
- Аўтэнтыфікацыя і аўтарызацыя: кожны запыт, зроблены ў API, павінен прайсці гэтыя дзве праверкі. Праверка асобы кліента праз аўтэнтыфікацыю і пацверджанне наяўнасці ў яго паўнамоцтваў на доступ да запытаных рэсурсаў праз аўтарызацыю - гэта два розныя працэсы.
- Праверка: перш чым API дасць доступ да сваіх рэсурсаў, запыты ўсё яшчэ павінны быць правераны на наяўнасць магчыма шкоднага кода пасля аўтэнтыфікацыі і аўтарызацыі. Такім чынам, сервер будзе адкрыты для ін'екцыйных нападаў.
- Праверка: перш чым API дасць доступ да сваіх рэсурсаў, запыты ўсё яшчэ павінны быць правераны на наяўнасць магчыма шкоднага кода пасля аўтэнтыфікацыі і аўтарызацыі. Такім чынам, сервер будзе адкрыты для ін'екцыйных нападаў.
- Шыфраванне: шыфраванне TLS/SSL абараняе злучэнне паміж кліентам і серверам і не дазваляе хакерам перахопліваць запыты і адказы.
- Метады абмежавання хуткасці, такія як ліміты і рэгуляванне, абараняюць серверы ад нападаў грубай сілы, такіх як DDoS, якія накіраваны на пагаршэнне або збой.
- Ніякай канфідэнцыйнай інфармацыі ў URI: URI рэсурсаў не павінны ўтрымліваць ніякіх абароненых даных (напрыклад, імя карыстальніка, пароль або маркер аўтэнтыфікацыі).
заключэнне
Віншую! Некалькі асноўных і складаных пытанняў інтэрв'ю па REST API і іх рашэнні цяпер у вас пад рукой.
Цяпер, калі ў вас ёсць добрая канцэпцыя таго, як адказваць на некаторыя тыповыя пытанні інтэрв'ю REST API, вы можаце перайсці да адказу на інтэрв'ю. Наступны крок залежыць ад вашых мэтаў.
візіт Серыял інтэрв'ю з Hashdork, каб падрыхтавацца да інтэрв'ю.
Пакінуць каментар