Мазмуну[Жашыруу][Көрсөтүү]
- 1. REST дегенди эмнени түшүнөсүз?
- 2. REST API дегенди эмнени түшүнөсүз?
- 3. URI деген эмне?
- 4. RESTful Web Services кандай мүнөздөмөлөргө ээ?
- 5. RESTтин негизги принциптери кайсылар?
- 6. REST колдогон HTTP ыкмаларын айтыңыз.
- 7. Ыңгайлуу интерфейс тарабынан коюлган чектөөлөрдү сүрөттөп бериңиз.
- 8. REST ресурсу деген эмне?
- 9. JAX-RS сиз үчүн эмнени билдирет?
- 10. AJAX жана REST бири-биринен эмнеси менен айырмаланат?
- 11. RESTful веб-кызматтарынын айрым кемчиликтерин санап бере аласызбы?
- 12. PUT жана POST ыкмалары бири-биринен эмнеси менен айырмаланат?
- 13. RESTful веб кызматтарын кантип сынайсыз?
- 14. Чыныгы дүйнөдө REST APIди сүрөттөп бериңиз.
- 15. Микросервис архитектурасы кантип иштейт?
- 16. Кэштөө деген эмне?
- 17. Пайдалуу жүктү сүрөттөп бериңиз.
- 18. САМЫН менен RESTти айырмалайсызбы?
- 19. Транспорттук катмардын коопсуздук протоколун (TLS) REST менен колдонсо болобу?
- 20. Идемпотенттик методдор: алар кандай? Бул RESTful веб кызматтарынын дүйнөсүнө кандайча колдонулат?
- 21. HTTP Негизги Аутентификациясынын функциясы кандай?
- 22. Сиз GraphQL микросервис архитектурасын түзүү үчүн эң жакшы тандоо деп ойлойсузбу?
- 23. Коопсуз жана идемпотенттүү HTTP ыкмаларынын негизги айырмачылыктары кандай?
- 24. JAX-RS API RESTful Root Resource Classes менен эмнени билдирет?
- 25. Почтачы деген эмне жана ал эмне үчүн колдонулат?
- 26. REST API'лери кантип коопсуз сакталат?
- жыйынтыктоо
RESTтин эволюциясы API'лерди укмуштуудай жеткиликтүү кылып, ошондой эле алардын толук күчүн жана потенциалын ачып берди. REST API'лери ресурска багытталган архитектурасынан улам түзүүгө жана кэштоого оңой.
Кошумча, убакыттын өтүшү менен, RESTful API'лер булуттагы эсептөө жана микросервиске негизделген дизайн сыяктуу башка маанилүү өнүгүүлөрдүн алдынкылары болгон.
Ошондуктан, REST API иштеп чыгуучулары RESTful кызматтарын атаандаштыкка жөндөмдүүлүктү колдонгон бизнести кантип камсыз кылышканын эске алганда, бүгүнкү күндө суроо-талапка ээ экендиги таң калыштуу эмес. REST API'лери популярдуу дизайн тенденциясы.
Көптөгөн IT фирмалары REST API билимин каалашат программа иштеп чыгуучулар жана техникалык интервьюларда бул тууралуу суроо.
Бул жерде REST API иштеп чыгуу тармагында иштегиңиз келсе, ар кандай фирмаларда интервьюга даяр болууга жардам бере турган эң типтүү REST API интервью суроолорунун айрымдары.
1. REST дегенди эмнени түшүнөсүз?
REST бул гипертекстти өткөрүү протоколуна (HTTP) негизделген веб-негизделген тиркемелерди иштеп чыгуу үчүн архитектуралык парадигма.
REST желе кызматтары RESTful деп эсептелиши керек болгон айрым стандарттарды аныктайт. Бул сунуштар стандартташтырылган HTTP протоколдорунун жардамы менен кардар менен сервердин ортосунда суроо-талаптар жана ресурстар тез жана эффективдүү берилээрин кепилдейт.
2. REST API дегенди эмнени түшүнөсүз?
Колдонмо программалоо интерфейси катары белгилүү болгон программалык камсыздоону программалык камсыздоого шилтеме башка көз карандысыз программалар ортосунда байланышты жана маалыматтарды алмашууну камсыз кылат. Мисалы, жаңылыктар веб-сайты тиешелүү твиттерди автоматтык түрдө таап, аларды жаңылыктарга бириктирүү үчүн Twitter API колдоно алат.
REST принциптерин карманган API REST API, кээде RESTful API катары белгилүү. REST APIде ар бир маалымат булак катары иштетилет жана өзүнчө стандарттык ресурстун идентификациясы (URI) берилет.
Мисалы, Twitter API ар бир твиттерди кардарлар үчүн жеткиликтүү болгон алынуучу булак кылат. Twitter API колдонуучулар тарабынан твиттерди жарыялоо жана веб-сайттын башка тапшырмаларын аткаруу үчүн колдонулушу мүмкүн.
3. URI деген эмне?
A желе ресурска URI же бирдиктүү ресурс идентификатору аркылуу кайрылса болот. Ал бир ресурсту башкасынан бөлүү каражаты катары кызмат кылат. Булактар онлайн болушу мүмкүн же жок болушу мүмкүн.
Өзүнүн стандарттуу түзүлүшүнөн улам, URI'лер ар кандай ресурстарга туташууну жеңилдетет. Ресурстун жайгашкан жери же аталышы символдор саптары менен бирге URIларга кошулат.
URI жол, схема, суроо жана башка элементтерден турат, бирок протоколду камтыбайт.
Протоколду колдонуу менен URL даректери (Бирдиктүү ресурстардын локаторлору) интернеттен ресурстарды табуу үчүн колдонулат же ал аркылуу жеткиликтүү.
4. RESTful Web Services кандай мүнөздөмөлөргө ээ?
- Кардар-Сервер парадигмасы кызматтын негизи болуп саналат.
- Кызмат URIларды колдонуу аркылуу ресурстарга кире алат.
- Кызмат маалымат/ресурстарды алуу, сурамдарды аткаруу жана башка тапшырмаларды аткаруу үчүн HTTP протоколун колдонот.
- Кабарлашуу - кардар менен сервердин ортосундагы байланыш үчүн колдонулган ыкманын аталышы.
- Бул кызматтар ошондой эле SOAP кызматтарын колдонуу менен REST архитектуралык үлгүсүн ишке ашыра алат.
- Ушундай эле кайталануучу суроо-талаптарга сервердик чалууларды азайтуу үчүн, бул кызматтар кэштөө идеясын да колдонушат.
5. RESTтин негизги принциптери кайсылар?
REST API'лери беш критерийге жооп бериши керек:
Кардар-серверди ажыратуу: Кардар менен сервердин ортосундагы байланыш үчүн бир катар суроо-талаптар жана жооптор гана колдонулушу мүмкүн. Кардарлар жана серверлер гана суроо-талаптарды жана жоопторду жөнөтө алышат. Бул түз идея эки тараптын бири-биринен көз карандысыз иштешине шарт түзөт.
Бирдиктүү интерфейс: Бардык кардар-сервер байланыштары үчүн бирдиктүү протокол болушу керек. REST үчүн бул протокол HTTP болуп саналат. Ар бир тиркеме бир тилди колдонуу менен маалыматтарды сурап жана жөнөткөндүктөн, ырааттуу интерфейс интеграцияларды жөнөкөйлөтөт.
Жарандыгы жок: Сервер жарандыгы жок байланышта мурунку сурамдардын же жооптордун эч кандай жазууларын сактабайт. Ар бир суроо-талап жана жооп алмашууну аяктоо үчүн зарыл болгон бардык маалыматтарды берет. Жарандыгы жок байланыш ылдамдыкты жогорулатат, эстутумду үнөмдөйт жана сервердеги стрессти азайтат. Кошумчалай кетсек, ал толук эмес маалыматтардан улам өтүнүчтүн аткарылбай калышынан сактайт.
Катмарлуу система: Кардар менен API серверинин ортосунда жайгашкан серверлер катмарлар деп аталат. Бул кошумча серверлер спамды аныктоо жана ылдамдыкты оптималдаштыруу сыяктуу ар кандай кызматтарды аткарышат. RESTтеги катмарлар модулдук, башкача айтканда, аларды кардар менен API серверинин ортосундагы байланышка таасир этпестен кошуп жана жок кылууга болот.
Кэштелет: Эгерде сервердин жооптору ресурстун кэштелет же жокпу көрсөтсө, кардарлар ылдамдыкты жогорулатуу үчүн каалаган ресурстарды кэштей алышат.
Талап боюнча коддоо: жооп катары, API кардарларга аткарылуучу компьютер кодун өткөрүп бере алат. Андан кийин кардар тиркемеси кодду өзүнүн арткы жагында иштете алат.
6. REST колдогон HTTP ыкмаларын айтыңыз.
REST колдогон HTTP ыкмалары болуп төмөнкүлөр саналат:
- GET: Бул ыкма көрсөтүлгөн URL боюнча ресурсту сурайт. Сурамдын органы кошулбашы керек, анткени ага көңүл бурулбайт. Аны жергиликтүү же серверде кэштөө мүмкүн.
- POST: Бул ыкма иштетүү үчүн кызматка маалыматтарды жөнөтөт жана кызмат адатта жаңы же өзгөртүлгөн ресурсту кайтарып бериши керек.
- PUT: Ресурс URL суроо-талабында жаңыртылды.
- DELETE: Ресурс суроо URL дарегинде жок кылынат.
- Параметрлер: Ал колдоого алынган ыкмаларды аныктайт.
- HEAD: Сурамдын URL метадайындары кайтарылды.
7. Ыңгайлуу интерфейс тарабынан коюлган чектөөлөрдү сүрөттөп бериңиз.
Кардарды серверден бөлүү үчүн ырааттуу интерфейс талап кылынат.
Ыңгайлуу интерфейске жетүү үчүн төмөнкү төрт чектөө талап кылынат:
- Ресурстарды идентификациялоо: Кардардын суроо-талаптары ресурстарды (URI) аныктоо үчүн стандарттык ресурс ID'лерин колдонушу керек
- Бул өкүлчүлүктөрдү колдонуу менен ресурстарды манипуляциялоо: Кардарлар серверден ресурстун өкүлчүлүгүн алганда ресурстун абалын өзгөртө алуу үчүн талап кылынган бардык маалыматка ээ.
- Өзүн-өзү сүрөттөгөн билдирүүлөр: Кабарлар бардык метадайындарды жана кабыл алуучунун аларды түшүнүшү үчүн зарыл болгон башка маалыматтарды камтыйт.
- Гипермедиа тиркеме абалынын кыймылдаткычы катары: кардар менен сервердин байланыш каналы HTML сыяктуу гипермедиа жана сервердин жоопторун түшүнүү үчүн кардарларга API спецификалык документациянын кереги жок.
8. REST ресурсу деген эмне?
Ресурстар REST архитектурасындагы RESTful веб сервисинин негизги компоненттери болуп саналат. Алар API кардары жетүү керек болгон бардык маанилүү маалыматтарды камтыйт.
HTML баракчасы, сүрөт, видео же API иш-аракети үчүн зарыл болгон башка нерселер сыяктуу ресурстардын ар кандай түрлөрүнө кардар-сервер системасындагы сервер аркылуу кирүүгө болот.
Ресурстар бирдиктүү ресурс идентификатору тарабынан аныкталат. Текст, JSON же XML ресурстардын бардык алгылыктуу өкүлчүлүктөрү болуп саналат. Белгилеп кетсек, өкүлчүлүктүн форматында эч кандай чектөөлөр жок.
9. JAX-RS сиз үчүн эмнени билдирет?
Көп учурда JAX-RS деп аталган RESTful веб-кызматтары үчүн Java API аркасында Java-да RESTful веб-кызматтарын түзүү оңой. Иштеп чыгуучулар берилген аннотацияларды колдонуу менен ресурстарды жана алар боюнча аткарыла турган операцияларды сүрөттөй алышат.
10. AJAX жана REST бири-биринен эмнеси менен айырмаланат?
Аякс:
- Ajax - бул динамикалык жаңыртууга мүмкүндүк берген технологиялардын тобу колдонуучу элементтери баракты кайра жүктөөсүз.
- Ajax кардар менен сервердин ортосундагы асинхрондук байланышты жок кылат.
ЭС АЛУУ:
- REST сервер менен кардар ортосундагы байланышты талап кылат.
- Ресурстарды колдонуу URL түзүмү жана REST колдонгон суроо-жооп үлгүсү үчүн маанилүү.
11. RESTful веб-кызматтарынын айрым кемчиликтерин санап бере аласызбы?
Кызматтар жарандыгы жок деген түшүнүктү кармангандыктан сессияларды улантуу мүмкүн эмес. (Кардар сеанстын идентификаторун сессиянын симуляциясы боюнча өткөрүү үчүн жооптуу.)
Коопсуздук чектөөлөрү REST үчүн негизги эмес. Аны колдонгон протоколдор коопсуздук чараларын мурастайт. Ошондуктан, SSL/TLS негизиндеги аутентификацияларды интеграциялоо сыяктуу коопсуздук чараларын колдонууда этият болуу маанилүү.
12. PUT жана POST ыкмалары бири-биринен эмнеси менен айырмаланат?
КОЮ:
- PUT жооптору үчүн кэш жок.
- Idempotent (башкача айтканда, бир нече суроо-талаптар бирдей натыйжа берет)
- суроо-талаптын пайдалуу жүгү максаттуу ресурсту жаңыртат же алмаштырат.
POST:
- idempotent эмес (б.а., бир нече суроо бир эле ресурстун эселенген санын берет)
- Веб сервер талап кылынган ресурстун негизинде суроо-талаптын пайдалуу жүгүн иштетет.
- Тийиштүү кэш-башкаруу темасы камтылган болсо, POST жоопторун кэштесе болот.
13. RESTful веб кызматтарын кантип сынайсыз?
RESTful веб-кызматын тестирлөөгө Swagger жана Postman сыяктуу бир катар куралдар жардам берет. Суроо параметрлери, баш жана жооп аталыштары сыяктуу суроо параметрлерин текшерүү акыркы функциялардын көптүгү менен мүмкүн болот.
Почтачы акыркы чекиттерге суроо-талаптарды жасоо жана натыйжаларды көрсөтүү үчүн колдонулушу мүмкүн. Жана бул жооптордон XML жана JSON түзүлүшү мүмкүн.
Почтачы жана Сваггер экөө тең өтө окшош функцияларды камсыз кылат. Башка жагынан алганда, Swagger ошондой эле акыркы чекиттин документтери сыяктуу мүмкүнчүлүктөрдү сунуш кылат.
14. Чыныгы дүйнөдө REST APIди сүрөттөп бериңиз.
- Саякат жана билеттерди сатуу веб-сайттары авиакомпаниялар API аркылуу жеткиликтүү кылган учуу убакыттарын жана баасын колдоно алышат.
- Карта түзүү жана навигация колдонмолору (мисалы, Google Карталар) аларды колдонуу үчүн, коомдук транспорт агенттиктери көбүнчө API аркылуу реалдуу убакыт режиминде өз маалыматтарын жалпыга жеткиликтүү кылат.
- Аба ырайы колдонмолору аба ырайы тууралуу маалыматты көрсөтүү үчүн аба ырайы маалыматтарын алмаштырган ачык API'лерди колдонушат.
- Иштеп чыгуучулар Google Карталардын картографиялык маалыматтарына анын бир катар жайгаштырылган API'лери аркылуу кире алышат. Бул API'лер иштеп чыгуучулар тарабынан алардын колдонмолоруна жана веб-сайттарына динамикалык карталарды киргизүү үчүн колдонулат.
15. Микросервис архитектурасы кантип иштейт?
- Суроо-талаптар ар кандай түзмөктөрдү колдонуу менен ар кандай кардарлар тарабынан жөнөтүлөт.
- Кардарлардын инсандыгын ырастагандан кийин, идентификациялоочулар коопсуздук белгилерин беришет.
- Кардардын суроо-талаптары API Gateway тарабынан башкарылат.
- Системанын бардык материалдары статикалык мазмун катары сакталат.
- Башкаруу куралы түйүндөрдөгү кызматтардын балансын жана бардык кемчиликтерди текшерет.
- Микросервистердин ортосундагы байланыш жолун табууга кызматтын ачылышы жардам берет.
- Маалымат борборлору жана прокси серверлер мазмун жеткирүү тармактары деп аталган дисперстүү тармак системаларын түзөт.
- Алыскы кызматтар алыстан маалыматка жетүүнү камсыз кылат.
16. Кэштөө деген эмне?
Сервердин жообун кийинчерээк тезирээк жетүү үчүн бир жерде (мисалы, компьютердин эс тутумунда) убактылуу сактоо практикасы кэш деп аталат.
Кэштөө сервердин суроо-талапты канааттандыруу үчүн аткарышы керек болгон иштин көлөмүн азайтып, REST APIлерди колдонууда сервердин ылдамдыгын жогорулатат. API колдонгон тиркемелер кэштин аркасында тезирээк иштейт, анткени алар ресурска муктаж болгон сайын жаңы сурам тапшырышпайт.
HTTP жооп аталышынын Кэш-башкаруу талаасы ресурска кайра кирүү керек болгонго чейин кардар тарабынан канча убакыт кэштеле тургандыгы жөнүндө маалыматты камтыйт.
17. Пайдалуу жүктү сүрөттөп бериңиз.
REST ичиндеги пайдалуу жүк HTTP жооптун денесинде камтылган маалыматты билдирет. Кардар каралып жаткан маалыматтарды суроо үчүн GET ыкмасын колдонгон.
Твиттин текстин камтыган документ жана твиттерди веб-сайтка коюу үчүн керектүү файлдар, мисалы, сиз Twitter API'ден белгилүү бир твиттерди сурасаңыз, пайдалуу жүккө кошулат. Кошумча, пайдалуу жүк POST ыкмасын колдонуу менен HTTP сурамына киргизилиши мүмкүн.
18. Дифференциациялоо САМЫН Vs REST?
- XMLди гана иштете алган SOAPдан айырмаланып, 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 методдору серверге бир эле же бир нече жолу жеткирилгенине да бирдей таасир тийгизет. Идемпотенттүү техникалар булар деп аталат.
Мисалы, GET ыкмасын колдонгон URI канча жолу иштетилбесин, сервер ар дайым бирдей натыйжага туш болот. Идемпотенттик методдор 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. JAX-RS API RESTful Root Resource Classes менен эмнени билдирет?
Java Enterprise Edition JAX-RS API талаптарына жооп берген класстарды жана интерфейстерди камсыз кылат. JAX-RS жардамы менен REST архитектуралык стилинде Java веб-кызматтарын түзүү жеңилдеди.
JAX-RS API'де тамыр ресурс класстары жөн гана "жөнөкөй эски Java объектилери" же POJO. Керектүү веб-ресурстарды ишке ашыруу үчүн алар JAX-RS аннотацияларын колдонушат.
Аларда @path аннотациялары бар же алардын ыкмаларынын жок дегенде биринде @path аннотациялары бар. Аларды API акыркы чекиттери менен иштөө ыкмалары менен Java класстары катары жыйынтыктоого болот.
25. Почтачы деген эмне жана ал эмне үчүн колдонулат?
Postman деп аталган API иштеп чыгуу куралы API'лерди түзүү, сыноо жана өзгөртүү үчүн колдонулат. Бул куралды иштеп чыгуучулар API үчүн талап кылынган бардык функциялар үчүн колдонсо болот. Ал иштеп чыгуучулардын ишин жеңилдетет жана жеңилдетет.
Почтачы ар кандай 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 интервьюсунун кээ бир типтүү суроолоруна кантип жооп берүү керектиги жөнүндө жакшы түшүнүккө ээ болгондон кийин, интервьюларга жооп берүүнү уланта аласыз. Кийинки кадам сиздин максаттарыңыздан көз каранды.
баруу Интервью сериясы Хашдорк менен интервьюга даярдануу үчүн.
Таштап Жооп