სარჩევი[დამალვა][ჩვენება]
- 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. განასხვავოთ საპონი დასვენებისგან?
- 19. შესაძლებელია თუ არა სატრანსპორტო ფენის უსაფრთხოების პროტოკოლის (TLS) გამოყენება REST-თან ერთად?
- 20. იდემპოტენტური მეთოდები: რა არის ისინი? როგორ ვრცელდება ეს RESTful ვებ სერვისების სამყაროში?
- 21. რა არის HTTP ძირითადი ავთენტიფიკაციის ფუნქცია?
- 22. როგორ ფიქრობთ, არის თუ არა GraphQL საუკეთესო არჩევანი მიკროსერვისის არქიტექტურის შესაქმნელად?
- 23. რა არის ძირითადი განსხვავებები უსაფრთხო და უიმედო HTTP მეთოდებს შორის?
- 24. რას გულისხმობს JAX-RS API RESTful Root რესურსების კლასებით?
- 25. კონკრეტულად რა არის ფოსტალიონი და რატომ გამოიყენება?
- 26. როგორ არის დაცული REST API-ები?
- დასკვნა
REST-ის ევოლუციამ API-ები წარმოუდგენლად ხელმისაწვდომი გახადა და ასევე გამოავლინა მათი სრული ძალა და პოტენციალი. REST API-ების შექმნა და ქეში მარტივია მათი რესურსებზე ორიენტირებული არქიტექტურის გამო.
გარდა ამისა, დროთა განმავლობაში, RESTful APIs იყო სხვა მნიშვნელოვანი განვითარების წინამორბედები, როგორიცაა ღრუბლოვანი გამოთვლა და მიკროსერვისზე დაფუძნებული დიზაინი.
აქედან გამომდინარე, გასაკვირი არ უნდა იყოს, რომ REST API დეველოპერები დღეს მოთხოვნადია, იმის გათვალისწინებით, თუ როგორ აწვდიან ბიზნესებს, რომლებიც იყენებენ RESTful სერვისებს კონკურენტულ უპირატესობას. REST API არის პოპულარული დიზაინის ტენდენცია.
ბევრ IT ფირმას სურს 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 Web Services-ს?
- კლიენტ-სერვერის პარადიგმა არის სერვისის საფუძველი.
- სერვისს შეუძლია რესურსებზე წვდომა URI-ების გამოყენებით.
- სერვისი იყენებს HTTP პროტოკოლს მონაცემების/რესურსების მოსაპოვებლად, მოთხოვნების გასაშვებად და სხვა ამოცანების შესასრულებლად.
- შეტყობინებები არის მეთოდის სახელი, რომელიც გამოიყენება კლიენტსა და სერვერს შორის კომუნიკაციისთვის.
- ამ სერვისებს ასევე შეუძლიათ დანერგონ REST არქიტექტურული ნიმუში SOAP სერვისების გამოყენებით.
- სერვერის ზარების შესამცირებლად იგივე სახის განმეორებით მოთხოვნებზე, ეს სერვისები ასევე იყენებენ ქეშირების იდეას.
5. რა არის REST-ის სახელმძღვანელო პრინციპები?
ხუთი კრიტერიუმი უნდა აკმაყოფილებდეს REST API-ებს:
კლიენტ-სერვერის განცალკევება: კლიენტსა და სერვერს შორის კომუნიკაციისთვის შეიძლება გამოყენებულ იქნას მხოლოდ მოთხოვნებისა და პასუხების სერია. მხოლოდ კლიენტებს და სერვერებს შეუძლიათ გაგზავნონ მოთხოვნები და პასუხები, შესაბამისად. ეს პირდაპირი იდეა საშუალებას აძლევს ორივე მხარეს იმოქმედოს ერთმანეთისგან დამოუკიდებლად.
ერთიანი ინტერფეისი: უნდა არსებობდეს ერთიანი პროტოკოლი კლიენტ-სერვერის ყველა კავშირისთვის. ეს პროტოკოლი REST-ისთვის არის HTTP. იმის გამო, რომ თითოეული აპლიკაცია ითხოვს და აგზავნის მონაცემებს იმავე ენის გამოყენებით, თანმიმდევრული ინტერფეისი ინტეგრაციას ამარტივებს.
მოქალაქეობის არმქონე: სერვერი არ ინახავს წინა მოთხოვნების ან პასუხების ჩანაწერებს მოქალაქეობის არმქონე კომუნიკაციაში. თითოეული მოთხოვნა და პასუხი შეიცავს ყველა დეტალს, რომელიც საჭიროა გაცვლის დასასრულებლად. მოქალაქეობის გარეშე კომუნიკაცია აძლიერებს სიჩქარეს, ზოგავს მეხსიერებას და ამცირებს სტრესს სერვერზე. გარდა ამისა, ის თავიდან აიცილებს მოთხოვნის წარუმატებლობის პოტენციალს არასრული მონაცემების გამო.
ფენიანი სისტემა: სერვერები, რომლებიც მდებარეობს კლიენტსა და API სერვერს შორის, მოიხსენიება როგორც ფენები. ეს დამატებითი სერვერები ასრულებენ სხვადასხვა სერვისს, როგორიცაა სპამის აღმოჩენა და სიჩქარის ოპტიმიზაცია. REST-ის ფენები მოდულარულია, რაც ნიშნავს, რომ მათი დამატება და წაშლა შესაძლებელია კლიენტსა და API სერვერს შორის კომუნიკაციაზე გავლენის გარეშე.
Cacheable: კლიენტებს შეუძლიათ ნებისმიერი რესურსის ქეშირება სიჩქარის გასაზრდელად, თუ სერვერის პასუხები მიუთითებს, არის თუ არა რესურსი ქეშირებადი.
მოთხოვნილ კოდირება: საპასუხოდ, API-ს შეუძლია კლიენტებს გადასცეს შესრულებადი კომპიუტერული კოდი. შემდეგ კლიენტის აპლიკაციას შეუძლია კოდის გაშვება საკუთარ უკანა მხარეს.
6. ახსენეთ HTTP მეთოდები, რომლებსაც REST უჭერს მხარს.
HTTP მეთოდები, რომლებსაც REST უჭერს მხარს, არის:
- GET: ეს მეთოდი ითხოვს რესურსს მითითებულ URL-ზე. მოთხოვნის ორგანო არ უნდა იყოს ჩართული, რადგან ის იგნორირებული იქნება. შესაძლებელია მისი ქეშირება ადგილობრივად ან სერვერზე.
- POST: ეს მეთოდი აგზავნის მონაცემებს სერვისს დასამუშავებლად და სერვისმა ჩვეულებრივ უნდა დააბრუნოს ახალი ან შეცვლილი რესურსი.
- PUT: რესურსი განახლებულია მოთხოვნის URL-ზე.
- წაშლა: რესურსი წაიშლება მოთხოვნის URL-ზე.
- ოფციები: ის განსაზღვრავს მხარდაჭერილ მეთოდებს.
- HEAD: მოთხოვნის URL-ის მეტამონაცემები დაბრუნდა.
7. აღწერეთ თანმიმდევრული ინტერფეისის მიერ დაწესებული შეზღუდვები.
კლიენტის სერვერისგან განცალკევების მიზნით, საჭიროა თანმიმდევრული ინტერფეისი.
თანმიმდევრული ინტერფეისის მისაღწევად, საჭიროა შემდეგი ოთხი შეზღუდვა:
- რესურსის იდენტიფიკაცია: კლიენტის მოთხოვნამ უნდა გამოიყენოს სტანდარტული რესურსის ID-ები რესურსების (URI) იდენტიფიცირებისთვის.
- რესურსების მანიპულირება ამ წარმომადგენლობების გამოყენებით: კლიენტებს აქვთ ყველა საჭირო ინფორმაცია, რათა შეძლონ რესურსის მდგომარეობის შეცვლა, როდესაც ისინი იღებენ რესურსის წარმოდგენას სერვერისგან.
- თვითაღწერითი შეტყობინებები: შეტყობინებები მოიცავს ყველა მეტამონაცემებს და სხვა ინფორმაციას, რომელიც საჭიროა მიმღებისთვის მათი გასაგებად.
- ჰიპერმედია, როგორც განაცხადის მდგომარეობის ძრავა: კლიენტ-სერვერის კომუნიკაციის არხი არის ჰიპერმედია, როგორიცაა HTML, და კლიენტებს არ სჭირდებათ API-ს სპეციფიკური დოკუმენტაცია სერვერის პასუხების გასაგებად.
8. კონკრეტულად რა არის REST რესურსი?
რესურსები არის RESTful ვებ სერვისის ფუნდამენტური კომპონენტები REST არქიტექტურაში. ისინი შეიცავს ყველა მნიშვნელოვან ინფორმაციას, რომელზეც API კლიენტს სჭირდება წვდომა.
ნებისმიერი ტიპის რესურსი, როგორიცაა HTML გვერდი, სურათი, ვიდეო ან სხვა რამ, რაც საჭიროა API აქტივობისთვის, შეიძლება იყოს წვდომა სერვერის მეშვეობით კლიენტ-სერვერის სისტემაში.
რესურსები იდენტიფიცირებულია ერთიანი რესურსის იდენტიფიკატორით. ტექსტი, JSON ან XML არის რესურსების მისაღები წარმოდგენები. ამის შემდეგ, არ არსებობს შეზღუდვები წარმომადგენლობის ფორმატში.
9. რას ნიშნავს თქვენთვის JAX-RS?
ჯავაში RESTful ვებ სერვისების შექმნა უფრო მარტივია RESTful ვებ სერვისებისთვის Java API-ის წყალობით, რომელიც ხშირად ცნობილია როგორც JAX-RS. დეველოპერებს შეუძლიათ აღწერონ რესურსები და ოპერაციები, რომლებიც შეიძლება განხორციელდეს მათზე მოწოდებული ანოტაციების გამოყენებით.
10. რა განასხვავებს AJAX-ს და REST-ს ერთმანეთისგან?
აიაქსი:
- Ajax არის ტექნოლოგიების ჯგუფი, რომელიც იძლევა დინამიური განახლების საშუალებას ინტერფეისი ელემენტები გვერდის გადატვირთვის გარეშე.
- Ajax ხსნის ასინქრონულ კომუნიკაციას კლიენტსა და სერვერს შორის.
დასვენება:
- REST მოითხოვს კომუნიკაციას სერვერსა და კლიენტს შორის.
- რესურსების გამოყენება მნიშვნელოვანია REST-ის მიერ გამოყენებული URL-ის სტრუქტურისა და მოთხოვნის/პასუხის ნიმუშისთვის.
11. შეგიძლიათ ჩამოთვალოთ RESTful ვებ სერვისების ნაკლოვანებები?
სხდომები არ შეიძლება გაგრძელდეს, რადგან სამსახურები იცავენ მოქალაქეობის არმქონეობის ცნებას. (კლიენტი პასუხისმგებელია სესიის ID-ის გადაცემაზე სესიის სიმულაციის განმავლობაში.)
უსაფრთხოების შეზღუდვები არ არის ფუნდამენტური REST-ისთვის. პროტოკოლები, რომლებიც მას იყენებენ, მემკვიდრეობით იღებენ უსაფრთხოების ზომებს. ამიტომ, უსაფრთხოების ზომების მიღებისას, როგორიცაა SSL/TLS-ზე დაფუძნებული ავთენტიფიკაციების ინტეგრირება, მნიშვნელოვანია სიფრთხილე.
12. რა განასხვავებს PUT და POST ტექნიკას ერთმანეთისგან?
ᲓᲐᲓᲔᲑᲐ:
- არ არის ქეში PUT პასუხებისთვის.
- იდემპოტენტური (ანუ მრავალი მოთხოვნა ერთსა და იმავე შედეგს გამოიღებს)
- მოთხოვნის payload განაახლებს ან ცვლის სამიზნე რესურსს.
პოსტი:
- 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-ს, უფრო სწრაფად მუშაობს ქეშირების წყალობით, რადგან მათ არ უწევთ ახალი მოთხოვნის წარდგენა ყოველ ჯერზე, როცა ესაჭიროებათ რესურსი.
HTTP პასუხის სათაურის ქეში-კონტროლის ველი შეიცავს ინფორმაციას იმის შესახებ, თუ რამდენ ხანს შეიძლება შეინახოს რესურსი კლიენტის მიერ, სანამ მას ხელახლა წვდომა დასჭირდება.
17. აღწერეთ ტვირთამწეობა.
REST-ში დატვირთვა ეხება HTTP პასუხის სხეულში არსებულ ინფორმაციას. მომხმარებელმა გამოიყენა GET ტექნიკა მოცემული მონაცემების მოსათხოვად.
დოკუმენტი, რომელიც შეიცავს ტვიტის ტექსტს და ყველა საჭირო ფაილს ვებსაიტზე ტვიტის განთავსებისთვის, ჩართული იქნება ტვიტერში, მაგალითად, თუ Twitter API-ს სთხოვთ კონკრეტულ ტვიტს. გარდა ამისა, payload შეიძლება ჩართული იყოს HTTP მოთხოვნაში POST მეთოდის გამოყენებით.
18. დიფერენცირება საპონი დასვენების წინააღმდეგ?
- განსხვავებით SOAP-ისგან, რომელსაც მხოლოდ XML-ის მართვა შეუძლია, REST იძლევა რესურსების ფორმატების უფრო ფართო სპექტრს, მათ შორის XML, ტექსტს, HTML-ს, სურათებს, ვიდეოს და სხვა.
- როდესაც უსაფრთხოება გადამწყვეტია ონლაინ აპლიკაციებისთვის, SOAP სასარგებლოა. REST-ის გამოყენება შეუძლებელია, როდესაც ტრანზაქციები უსაფრთხოდ უნდა დასრულდეს, რადგან ის არ არის განსაკუთრებით უსაფრთხო.
- ვინაიდან SOAP მხოლოდ პროტოკოლია, REST-ს შეუძლია გამოიყენოს იგი თავის ვებ სერვისებში, მაგრამ არა პირიქით.
- მიუხედავად იმისა, რომ REST მხოლოდ არქიტექტურული ნიმუშია, რომელიც გამოიყენება ვებ სერვისების შესაქმნელად და ემორჩილება გარკვეულ შეზღუდვებს, როგორიცაა კლიენტ-სერვერის დაყენება, მოქალაქეობის არარსებობა, ქეშირებადი პასუხი, ფენიანი სისტემები და თანმიმდევრული ინტერფეისი, SOAP არის პროტოკოლი, რომელიც მოქმედებს კონკრეტულ სტანდარტებზე, რომლებიც მკაცრად უნდა იყოს დაცული. რომ.
- მიუხედავად იმისა, რომ REST იყენებს უნივერსალური რესურსის იდენტიფიკატორებს (URIs), 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, რომ დავასახელოთ რამდენიმე.
Idempotent HTTP მეთოდები არის ზოგიერთი მათგანი, რომელსაც იყენებს RESTful ვებ პროგრამები. ისინი აუცილებელია RESTful ვებ სერვისების საქმიანობის თანმიმდევრულობის უზრუნველსაყოფად.
კლიენტებს, რომლებიც იყენებენ REST API-ებს, შეუძლიათ დაუშვან კოდის შეცდომები, რაც აიძულებს REST API-ს შემთხვევით განმეორებითი მოთხოვნები გააკეთოს. ამ ზარებს აქვს რესურსების ბოროტად გამოყენების პოტენციალი.
21. რა არის HTTP ძირითადი ავთენტიფიკაციის ფუნქცია?
ძირითადი ავთენტიფიკაციის API-ების ნაწილად გამოყენებისას მომხმარებელმა უნდა წარადგინოს მომხმარებლის სახელი და პაროლი, რომლებიც დაკავშირებულია ბრაუზერის მიერ „მომხმარებლის სახელი: პაროლი“ სახით და დაშიფრულია base64.
ბრაუზერის ყოველი HTTP მოთხოვნისას, კოდირებული მნიშვნელობა მიეწოდება როგორც მნიშვნელობა „ავტორიზაციის“ სათაურისთვის. იმის გამო, რომ რწმუნებათა სიგელები უბრალოდ დაშიფრულია, რეკომენდებულია ამ ფორმის გამოყენება HTTPS მოთხოვნების გაგზავნისას, რადგან ისინი არ არის დაცული და შეიძლება ვინმემ ხელი შეუშალოს, თუ უსაფრთხოების პროტოკოლები არ არის გამოყენებული.
22. როგორ ფიქრობთ, არის თუ არა GraphQL საუკეთესო არჩევანი მიკროსერვისის არქიტექტურის შესაქმნელად?
Microservices და GraphQL იდეალურად მიდის, რადგან GraphQL ინახავს თქვენს მიკროსერვისის არქიტექტურას თქვენი კლიენტებისგან.
წინა ბოლოდან, გსურთ, რომ თქვენი ყველა მონაცემი მოდიოდეს ერთი API-დან, ხოლო უკანა ბოლოდან, გსურთ მისი დაყოფა მიკროსერვისებად. საუკეთესო ტექნიკა, რომელიც მე ვიცი ორივეს მისაღწევად არის GraphQL-ის გამოყენება.
ეს საშუალებას გაძლევთ დაყოთ თქვენი ბექენდი მიკროსერვისებად, ხოლო თითოეულ აპლიკაციას ერთ API-ს ანიჭებთ და სხვადასხვა სერვისების მონაცემებს შორის შეერთების ჩართვას.
23. რა არის ძირითადი განსხვავებები უსაფრთხო და უიმედო HTTP მეთოდებს შორის?
იდემპოტენტური მეთოდები იძლევა ერთსა და იმავე შედეგს, როდესაც გამოიყენება ერთხელ ან რამდენჯერმე ერთი და იგივე მოთხოვნის მეშვეობით. PUT მეთოდი იდემპოტენტურია.
ყველა უსაფრთხო გზა იდემპოტენტურია, მაგრამ ყველა იდემპოტენტური მეთოდი არ არის უსაფრთხო, რადგან უსაფრთხო მეთოდები არ ცვლის რესურსებს. მაგალითად, GET უსაფრთხოა, რადგან ის უბრალოდ იბრუნებს მონაცემებს და არ ცვლის რესურსს.
გარდა ამისა, ის იდემპოტენტურია, რაც იმას ნიშნავს, რომ გამოძახებისას ყოველთვის იგივე პასუხს უბრუნებს.
24. რას გულისხმობს JAX-RS API RESTful Root რესურსების კლასებით?
Java Enterprise Edition გთავაზობთ კლასებსა და ინტერფეისებს, რომლებიც იცავენ JAX-RS API-ს მოთხოვნებს. JAX-RS-ის დახმარებით გაადვილებულია Java ვებ სერვისების შექმნა REST არქიტექტურულ სტილში.
JAX-RS API-ში, ძირეული რესურსების კლასები არის მხოლოდ „უბრალო ძველი java ობიექტები“ ან POJO. საჭირო ვებ რესურსების დანერგვის მიზნით, ისინი იყენებენ JAX-RS ანოტაციებს.
მათ ან აქვთ @path ანოტაციები ან მათ ერთ მეთოდს მაინც აქვს @path ანოტაციები. ისინი შეიძლება შეჯამდეს როგორც Java კლასები API ბოლო წერტილებთან გამკლავების მეთოდებით.
25. კონკრეტულად რა არის ფოსტალიონი და რატომ გამოიყენება?
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 ინტერვიუს კითხვებს, შეგიძლიათ გააგრძელოთ ინტერვიუებზე პასუხი. შემდეგი ნაბიჯი დამოკიდებულია თქვენს მიზნებზე.
ვიზიტი ინტერვიუს სერია ჰაშდორკთან ინტერვიუებისთვის მოსამზადებლად.
დატოვე პასუხი