ეს სტატია აღწერს ამ არქიტექტურის საფუძვლებს, მის შესაძლებლობებსა და აპლიკაციებს.

რა არის REST?

REST ვარიანტს აქვს ძალიან მარტივი ინტერფეისი ინფორმაციის სამართავად ყოველგვარი დამატებითი შიდა დამუშავების გარეშე. ინფორმაციის თითოეული ნაწილი ცალსახად იდენტიფიცირებულია გლობალური იდენტიფიკატორით, როგორიცაა URL. თითოეულ URL-ს, თავისებურად, აქვს მკაცრად დავალების ფორმატი.

ახლა კი, ყველაზე მკაფიოდ:

დამატებითი შიდა ძიებების არსებობა ნიშნავს მონაცემთა გადაცემას ისევე, როგორც თავად მონაცემები. ტობტო. ჩვენ არ ვწვავთ მონაცემებს XML-ში, ისევე როგორც SOAP და XML-RPC, არ ვიყენებთ AMF-ს, ისევე როგორც Flash-ს და ა.შ. ჩვენ მხოლოდ თავად ვაძლევთ მონაცემებს.

ინფორმაციის თითოეული ნაწილი ცალსახად იდენტიფიცირებულია URL-ით, რაც ნიშნავს, რომ URL არის ინფორმაციის ნაწილის ძირითადი გასაღები. ტობტო. მაგალითად, პოლიციის წიგნის მესამე წიგნი ჰგავს /book/3-ს, ხოლო 35-ე გვერდი ამ წიგნის ჰგავს /book/3/page/35. Zvіdsi y ამოცანების ფორმატი. უფრო მეტიც, საერთოდ არ აქვს მნიშვნელობა რა ფორმატშია მონაცემები განთავსებული მისამართზე /book/3/page/35 - ეს შეიძლება იყოს HTML, jpeg ფაილის სახით დასკანირებული ასლი ან Microsoft Word დოკუმენტი.

სერვისის მიერ ინფორმაციის მართვა მთლიანად ეფუძნება გადაცემის პროტოკოლს. ყველაზე მოწინავე პროტოკოლი აშკარად არის HTTP. ასე რომ, HTTP-სთვის, მონაცემებზე მოქმედება განისაზღვრება შემდეგი მეთოდებით: GET (წაშლა), PUT (დამატება, ჩანაცვლება), POST (დამატება, შეცვლა, წაშლა), DELETE (წაშლილი). ამრიგად, CRUD (Create-Read-Updtae-Delete) ოპერაციების დასრულება შესაძლებელია ნებისმიერი რაოდენობის მეთოდის გამოყენებით, მათ შორის GET და POST.

ღერძი ასე გამოიყურება კონდახზე:

GET /book/ - მოიძიეთ ყველა არსებული წიგნის სია
მიიღეთ /წიგნი/3/ - მიიღეთ წიგნი ნომერი 3
PUT /book/ - დაამატეთ წიგნი (მონაცემები მომხმარებლისგან)

წაშლა /წიგნი/3 – წიგნის ნახვა

მნიშვნელოვანი დამატება:მათ უწოდებენ REST- შაბლონებს, რომლებიც დაკავშირებულია HTTP მეთოდებთან, რომლებიც უნდა დაირღვეს. სახლთან უფრო ახლოს, სხვადასხვა მოდელები სხვადასხვანაირად უყურებენ POST-ს და PUT-ს. თუმცა, PUT არ არის მინიჭებული შექმნის, განმეორებისა და განახლებისთვის, მაგრამ POST-ისთვის არ არის დავალება (POST ოპერაცია ძალიან ზოგადია და მას რაიმე კონკრეტული მნიშვნელობა არ შეიძლება დაერთოს). მაშასადამე, ჩემი მაგალითი ამ ფორმით სწორი იქნება და თითქოს თქვენ გულისხმობთ POST და PUT ურთიერთშემცვლელად.

კიდევ ერთხელ, POST შეიძლება შეიცვალოს ერთდროულად ყველა ცვლილებისთვის:
POST /წიგნი/ – დაამატეთ წიგნი (მონაცემები მოთხოვნილია)
POST /წიგნი/3 – შეცვალეთ წიგნი (მოთხოვნილი იქნება მონაცემები)
POST /წიგნი/3 – წაშალე წიგნი (სხეული ცარიელი იქნება)

ეს საშუალებას გაძლევთ ზოგჯერ უგულებელყოთ უსიამოვნო მომენტები, რომლებიც დაკავშირებულია PUT და DELETE პრობლემებთან.

REST ვიკი ყოველდღიური ვებ სერვისებისთვის.

კანის ინფორმაციის ერთეულისთვის მითითებულია 5 მოქმედება. და საკუთარ თავს:

Ინფორმაციის მიღება/ (ინდექსი)- აჩვენებს ყველა ობიექტის სიას. პატიებისკენ მოუწოდე, ესე იგი. მოათავსეთ მხოლოდ იდენტიფიკატორის და ობიექტის სახელის ველები, სხვა მონაცემების გარეშე.

მიიღეთ /info/(id) (ნახვა)- ამოიღებს მეტ ინფორმაციას ობიექტის შესახებ.

PUT /ინფორმაცია/ან კიდევ პოსტი /ინფორმაცია/ (Შექმნა)- ახალ ობიექტს ვქმნი. მონაცემები სხეულში გადაიცემა ფორმალური კოდირების გარეშე, urlencode-ის გამოყენებით. PHP-ში სხეული შეიძლება დაიწეროს ამ გზით:

ფუნქცია getBody() (
თუ (!isset($HTTP_RAW_POST_DATA))
$HTTP_RAW_POST_DATA = file_get_contents ("php://input");
დააბრუნეთ $HTTP_RAW_POST_DATA;
}

გამოქვეყნება /ინფორმაცია/(id)ან კიდევ PUT /info/(id) (რედაქტირება)– ცვლის მონაცემებს იდენტიფიკატორით (id), შესაძლოა შეცვალოს ისინი. მონაცემები ასევე გადადის მოთხოვნის სხეულში, მაგრამ PUT რეჟიმში არის მნიშვნელოვანი ნიუანსი. მარჯვნივ, POST მოთხოვნა გადასცემს urldcoded-post-მონაცემების არსებობას. ტობტო. თუ კოდს არ სტაგნაცია, ეს არ არღვევს სტანდარტს. აქ ვისაც უნდათ, სტანდარტისადმი პატივისცემას არ ავლენენ, ვიკორისტებენ თითქოს ცვლილებების შემდგომ იყვნენ.

წაშლა /info/(id) (წაშლა)– წაშლის მონაცემებს იდენტიფიკატორიდან (id).

ნება მომეცით კიდევ ერთხელ აღვნიშნო, რომ ჩვენს აპლიკაციაში /info/ - ის შეიძლება ეფუძნებოდეს ნებისმიერ სხვა ინფორმაციას, რომელიც შეიძლება (და შეიძლება) იყოს ნაჩვენები URL-ში:

/data/4/otherdata/6/info/3/ … ეს არის ის.

რა შეგიძლიათ მიიღოთ ამ კონცეფციიდან:

როგორც ჩანს, REST არქიტექტურა განვითარების თვალსაზრისით ძალიან მარტივია. ერთი შეხედვით, შეგიძლიათ გაიგოთ, რა მუშაობს ფორმატების გაგების გარეშე (SOAP, XML-RPC). მონაცემები გადაიცემა დამატებითი მონაცემების შენახვის გარეშე, ამიტომ REST ითვლება ნაკლებად რესურსზე ინტენსიურად, რადგან ის არ საჭიროებს ანალიზს იმის გასაგებად, თუ რა უნდა გაკეთდეს და არ საჭიროებს მონაცემთა გადაცემას ერთი ფორმატიდან მეორეში.

უფრო პრაქტიკული ვიდრე სტაგნაცია.

REST არქიტექტურა საშუალებას გაძლევთ სერიოზულად გაამარტივოთ დავალება. ეს განსაკუთრებით ეხება ფუნქციონალურობას, მაგრამ ცოტა რამ არის აღწერილი და მაშინაც კი, თუ შეუძლებელია ვინმეს ინფორმაციის შეცვლის შესაძლებლობა, მაშინ ასევე საჭიროა ავტორიზაცია და ავთენტიფიკაცია. ეს მარტივად შეიძლება გაკეთდეს ნებისმიერი სხვა ტიპის სესიის ან უბრალოდ HTTP ავთენტიფიკაციის გამოყენებით.

REST API (Representational State Transfer), ან RESTful ვებ სერვისები, რა არის ეს? REST ითარგმნა ინგლისურიდან, როგორც "წარმომადგენლობითი გადაცემა stan-ზე". ეს არის ინტერნეტში კომპიუტერულ სისტემებს შორის ურთიერთქმედების უზრუნველყოფის მეთოდი. REST-ზე დაფუძნებული ვებ სერვისები, რომლებიც საშუალებას აძლევს სისტემებს, რომლებიც მოიხმარენ, უარყოფენ წვდომას ტექსტზე დაფუძნებულ ვებ რესურსებზე და ამუშავებენ მათ, vikoryst და ერთიან ოპერაციებს. გამოიკვლიეთ ვებ სერვისების სხვა ფორმები, რომლებიც აერთიანებს მათ ძალას ოპერაციების დამატებით კომპლექტებთან, როგორიცაა WSDL და SOAP.

REST API: რა არის ეს? მე მესმის

ვებ რესურსები, პირველ რიგში, იდენტიფიცირებულია მსოფლიო ქსელიდან, როგორც დოკუმენტები ან ფაილები, რომლებიც იდენტიფიცირებულია მათი URL-ებით. დღევანდელი სუნი შეიძლება იყოს უფრო ბუნდოვანი და აბსტრაქტული მნიშვნელობით, რომელიც აგრძნობინებს კანის ობიექტს და რეალობას, რომლის ამოცნობა, დასახელება, მიმართვა და შეგროვება შესაძლებელია მერეჟში. REST API ვებ სერვისი ითხოვს პასუხს URI რესურსში, რომელიც შეიძლება დაფორმატდეს XML, HTML, JSON ან სხვა ფორმატში. თქვენ შეგიძლიათ დაადასტუროთ, რომ ცვლილებები განხორციელდა შენახულ რესურსში, ისევე როგორც ჰიპერტექსტური შეტყობინებების გაგზავნა სხვა დაკავშირებულ რესურსებსა და მათ კოლექციებში. HTTP-ის გამოყენება, როგორც ყველაზე გაფართოებული პროტოკოლი, ვრცელდება ხელმისაწვდომი ოპერაციების ტიპებზე, რომლებიც მითითებულია ბრძანებებით PUT, DELETE, HTTP GET, POST.

გამარჯვების პროტოკოლები რეგულირების გარეშე გახდება სტანდარტული ოპერაციები, REST სისტემები მიმართულია მაღალ პროდუქტიულობაზე, საიმედოობაზე და ხელმისაწვდომობაზე, რათა გაიზარდოს რე-ვიკორისტული კომპონენტების რაოდენობა, რომლებიც შეიძლება დამუშავდეს და რომლებიც შეიძლება განახლდეს სისტემაში ჩარევის გარეშე. REST ვებსაიტები ხშირად უფრო მარტივი და ნაკლებად მნიშვნელოვანია SOAP (Simple Object Access Protocol) სტილში, ხოლო REST ქსელებს არ აქვთ იგივე გამტარუნარიანობის ხარჯები, რაც მათ უფრო შესაფერისს ხდის ინტერნეტის ვებსაიტებს. SOAP მიდგომისთვის, თქვენ უნდა დაწეროთ ან შექმნათ სერვერის პროგრამა (მონაცემების მომსახურებისთვის) და კლიენტის პროგრამა (მონაცემების შესანახად).

ტექნოლოგიის ისტორია

ტერმინი „წარმომადგენლობითი ტრანსფერი ქვეყანაში“ შემოიღო და გამოიყენა 2000 წელს როი ფილდინგმა თავის დისერტაციაში „არქიტექტორული სტილები და დიზაინი პროგრამული უზრუნველყოფის არქიტექტურის ზღვარზე“. ჩვენ განვავითარეთ REST-ის არქიტექტურული სტილი HTTP 1.1-ის პარალელურად 1996-1999 წლებში, ძირითადი პროექტის HTTP 1.0 1996 წლის საფუძველზე. ტექნოლოგიის განვითარების რეტროსპექტული შეხედვისას, ფილდინგმა თქვა, რომ HTTP სტანდარტიზაციის პროცესში, სავარაუდოდ, ინტერნეტში დიზაინის არჩევანი მოიპარა. ეს უფრო რთული პროცესია იმ პროცესის ფარგლებში, რომელიც ნებისმიერისგან იღებს წინადადებებს იმის შესახებ, თუ როგორ ხდება შვედეთი ამ გალუზას ცენტრში.

500-ზე მეტი კონტრიბუტორის კომენტარების მიწოდება, რომელთაგან ბევრი დიდი ცოდნის მქონე ინჟინრებია. თქვენზეა დამოკიდებული ყველაფრის ახსნა, ვებ-ურთიერთქმედების აბსტრაქტული გაგებიდან დაწყებული HTTP სინტაქსის ზუსტ დეტალებამდე. ამ პროცესმა დახვეწა ეს მოდელი პრინციპების, პრინციპებისა და ჩარჩოების ძირითად კომპლექტად, რომელსაც ახლა REST ეწოდება.

უპირატესობები

REST სტილის თავისებურებები გამომდინარეობს შემდეგი არქიტექტურული პრინციპებიდან:

• პროდუქტიულობა - კომპონენტებისა და დომინანტური ავტორიტეტების ურთიერთქმედება პროდუქტიულობისა და ეფექტურობის ღონისძიებების მართვაში.
• მასშტაბურობა კომპონენტების მაქსიმალური რაოდენობის მხარდასაჭერად, REST API-ების ტესტირება და მათ შორის ურთიერთქმედება.
• ერთი ინტერფეისის სიმარტივე და ავტორიზაციის REST API.
• კომპონენტების მოდიფიკაცია კონკრეტული საჭიროებების დასაკმაყოფილებლად (ოპერაციული პროგრამების მიხედვით).
• კომუნიკაციის ხილვადობა საწყობსა და სერვის აგენტებს შორის.
• კომპონენტების პორტირების შესაძლებლობა, რომლებიც გადააქვთ მათი პროგრამის კოდს მონაცემებით.
• საიმედოობა - მაღალი წინააღმდეგობა წარუმატებლობის მიმართ საწყობში ჩავარდნის, გათიშვის ან მონაცემების შემთხვევაში.

კლიენტებს შორის პრობლემების დიაპაზონი აიხსნება იმით, რომ REST API საშუალებას გაძლევთ იგრძნოთ კომპონენტების განხორციელება, ცვლის კონექტორის სემანტიკის სირთულეს, ხელს უწყობს პროდუქტიულობის კორექტირების ეფექტურობას და ხელს უწყობს სუფთა სერვერის კომპონენტების მასშტაბურობას iv. კომპაქტური სისტემური ურთიერთკავშირები საშუალებას აძლევს შუამავლებს - პროქსიებს, კარიბჭეებს და ფეიერვოლებს დაუკავშირდნენ სხვადასხვა წერტილში კომპონენტებს შორის ინტერფეისის შეცვლის გარეშე, რაც მათ საშუალებას აძლევს განახორციელონ REST-გადაცემა ან გადაიტანონ Vati პროდუქტიულობა ფართომასშტაბიანი zagalny keshuvannya-ს დახმარებით. REST API-ს გამოყენება განპირობებულია იმით, რომ თუ ურთიერთქმედება არ არის მოთხოვნის სახით, სემანტიკისა და ინფორმაციის გაცვლის დასადგენად გამოიყენება სტანდარტული მეთოდები და მედიის ტიპები, ხოლო შედეგები ცალსახად მიუთითებს ქეშირებაზე.

ფორმალური და არქიტექტურული საზღვრები

ექვსი ძირითადი ზღვარი ახასიათებს RESTful სისტემას. ისინი განსაზღვრავენ გზებს, რომლითაც სერვერს შეუძლია კლიენტებისგან მოთხოვნების დამუშავება და მიღება. ამ ურთიერთქმედების ფარგლებში, სერვისი გამორიცხავს არაფუნქციური სიმძლავრის ელემენტებს, როგორიცაა პროდუქტიულობა, მასშტაბი, სიმარტივე, სიმრავლე, ხილვადობა, მობილურობა და საიმედოობა. თუ სერვისი წყვეტს ნებისმიერ საჭირო კავშირს, ის არ შეიძლება იყოს დასვენება.

პირველი საზღვრები მიყვანილია კლიენტ-სერვერის არქიტექტურულ სტილში. კლიენტის ინტერფეისის პრობლემების შემცირება და მონაცემთა შენახვის პრობლემები გააუმჯობესებს კლიენტის ინტერფეისის პორტაბელურობას რამდენიმე პლატფორმაზე. ის ასევე აუმჯობესებს მასშტაბურობას სერვერის კომპონენტების გამარტივებით. მერეჟასთვის, ალბათ, ყველაზე მნიშვნელოვანი ის არის, რომ ის საშუალებას აძლევს კომპონენტებს დამოუკიდებლად განვითარდნენ, რითაც საშუალებას მისცემს ინტერნეტის მასშტაბის დიდ ორგანიზაციულ დომენებს.

Უსაფრთხოება

REST არ უზრუნველყოფს უსაფრთხოების საჭირო მხარდაჭერას. ეს განსაკუთრებით მნიშვნელოვანია REST ვებ სერვისების შემუშავებისას - უსაფრთხოებისა და დიზაინის გათვალისწინება. REST ვებ სერვისები იყენებენ HTTP PUT და DELETE CRUD ოპერაციებით. PUT და DELETE არ არის მხარდაჭერილი მრავალი ბრაუზერის მიერ და ყველაზე ხშირად დაკავშირებულია თანატოლ სერვერებთან კონფიდენციალურობის დარღვევის შესაძლებლობის გამო. თუ სერვერსა და კლიენტს შორის არ არის სათანადო დაყენება, ნებისმიერ მესამე მხარის კლიენტს შეუძლია შექმნას რესურსი PUT მეთოდის გამოყენებით ან სხვა DELETE რესურსის გამოყენებით. განვითარების პერიოდში შესაძლებელი იყო ვებ სერვისების უსაფრთხოების უზრუნველყოფა და ამ მომენტების დაცვა.

არქიტექტურული ელემენტები

REST-ის ძირითადი ასპექტია მისი მონაცემთა ელემენტების ბუნება. REST სტილს აქვს რამდენიმე კონცეფცია, რომელიც აღწერს ინფორმაციის ქცევას და წარმოებას.

რესურსი არის ობიექტი (ლოგიკური ან ფიზიკური) ხელმისაწვდომი ინტერნეტში. ეს შეიძლება იყოს დოკუმენტი, რომელიც ინახება სერვერის ფაილურ სისტემაში ან მწკრივი მონაცემთა ბაზის ცხრილში. ტერმინალი koristuvach ურთიერთქმედებს რესურსთან სიმღერის ნიშნის მისაღწევად. REST-ის გამოყენებით სისტემის შესაქმნელად, დიზაინერმა უნდა იფიქროს ბიზნეს ობიექტებზე, როგორც რესურსებზე და მათზე, რომელთა მიმართაც შესაძლებელია.

URI - ცალსახად განსაზღვრავს რესურსს. ეს პარამეტრი ცვლის მისამართის რესურსს და შეიძლება შეიცვალოს. რესურსების გაცვლა ხდება პროტოკოლით მხარდაჭერილ პროგრამებზე, როგორიცაა HTTP.

პოდანნია - ამ მომენტში მე გავხდები რესურსი. კლიენტი აბრუნებს მოთხოვნას რესურსზე, რომელსაც მოჰყვება URI. რესურსის ნახვა შესაძლებელია ერთ ან მეტ ფორმატში, რომლებიც გადაცემულია, როგორიცაა XML, HTML, JSON, RSS, REST API java. ეს ფორმატები შეიძლება განთავსდეს კონტენტის გაუმჯობესების დამატებითი მექანიზმით.

უფლება - პროგრამას საშუალებას აძლევს გააუქმოს გადასვლა ერთი მდგომარეობიდან მეორეზე. თითოეულ რესურსს შეიძლება ჰქონდეს კავშირი სხვა რესურსებთან. დღევანდელმა შეიძლება დაადასტუროს ამოქმედება მომავალი გადასვლისთვის. კარგად დაკავშირებული პროგრამა საშუალებას აძლევს მომხმარებელს დამოუკიდებლად გახსნას ინტერფეისი.

კონექტორი

კავშირი არის აბსტრაქტული ინტერფეისი, რომელიც შუამავლობს კომპონენტებს შორის კავშირებს. REST ურთიერთქმედების ფრაგმენტები არ არის წაშლილი, კონექტორი არ არის პასუხისმგებელი ქსელის შესახებ ინფორმაციის შენახვაზე. ამიტომ, კომპონენტებს შორის კავშირები შეიძლება შეიქმნას პარალელურად.

კლიენტი და სერვერი არის მთავარი REST კონექტორები. კლიენტი იწყებს მოთხოვნას და სერვერი ამუშავებს მას.

ნაღდი ფული როჟემის სხვა სახეობაა. ქეშირება შეიძლება განხორციელდეს კლიენტზე, სერვერზე და სხვა დონეზე. ეს ცვლის აღდგენის საათს და საზღვრების სიახლოვეს.

კომპონენტები

კომპონენტების აწყობა ხდება მკაცრად განსაზღვრული რესურსის მეთოდებით, რაც ქმნის პირობებს საწარმოო და გადასატანი ქარხნის შესანახად.

მომხმარებელი-აგენტი – vikoryst კლიენტის კავშირი მოთხოვნის დასაწყებად.

Origin-server – Vikorist სერვერის კონექტორი ელექტრომომარაგებისთვის.

პროქსი არის შუამავალი, რომელიც გამოიყენება კლიენტის მხარეს ინტერფეისის სხვა სერვისებთან ჩასაწერად. ის ასევე მოიცავს მონაცემთა თარგმნას და დაცვას.

კარიბჭე არის შუამავალი, რომელიც დაინსტალირებულია სერვერზე, რათა უზრუნველყოს ინტერფეისის ინკაფსულაცია სხვა სერვისებით.

განვითარების პერსპექტივები

ახალი რელევანტური საკვები: REST API - რა არის ეს თანამედროვე ინტერნეტ ტექნოლოგიებისთვის? REST არის თანამედროვე ვებ არქიტექტურის საფუძველი, რომელიც შემუშავებულია რამდენიმე არსებული სტილის ანალიზით და მასში ახალი დამატებების დანერგვით.

REST API-ს მიზნები - რა არის ეს? მიზანია განსხვავებული სტილის შერწყმა საზღვრების კოორდინირებულ კომპლექტთან, რათა მინიმუმამდე დაიყვანოს შეჯახება და მაქსიმალურად გაზარდოს კომპონენტების დამოუკიდებელი ევოლუცია მასშტაბის მისაღწევად. ახალი ჰიპერმედია არქიტექტურის ფასი. სმარტფონების, ტაბლეტების და გაჯეტების მოსვლასთან ერთად, არსებობს მასშტაბის საზომი.

RESTful API შეიძლება შეიქმნას მესამე მხარის სერვისებისთვის. შეგიძლიათ გამოიყენოთ ცალმხრივი რობოტების პროგრამები უკანა ნაწილით. არსებობს მთელი რიგი ძირითადი პუნქტები, რომლებიც უნდა იცოდეთ ინტერფეისის შექმნამდე.

URL და პირობები

REST-ის მთავარი პრინციპია თქვენი API ლოგიკურ რესურსებად დაყოფა. ამ რესურსების მართვა ხორციელდება დამატებითი HTTP მოთხოვნების გამოყენებით სტანდარტული მეთოდით – GET, POST, PUT, PATCH, DELETE.

რესურსი უნდა იყოს აღწერილი სიმრავლის სახელით. რესურსებზე მოქმედებები განისაზღვრება CRUD სტრატეგიის გამოყენებით და მხარდაჭერილია HTTP მეთოდებით შემდეგი თანმიმდევრობით:

• GET /api/users – მოიძიეთ კლიენტების სია;
• GET /api/users/123 - აირჩიეთ მითითებული მომხმარებელი;
• POST /api/users – შექმენით ახალი მომხმარებელი;
• PUT /api/users/123 - განაახლეთ მითითებული ანგარიშის მენეჯერის ყველა დეტალი;
• PATCH /api/users/123 – კორისტუვაჩის მონაცემების ნაწილობრივ განახლება;
• წაშლა /api/users/123 - vidaliti koristuvach.

ვინაიდან რესურსი არსებობს მხოლოდ სხვა რესურსის კონტექსტში, URL შეიძლება გაერთიანდეს:

• მიიღეთ /api/posts/9/comments - გადაახვიეთ კომენტარების სია No9 ჩანაწერამდე;
• მიიღეთ /api/posts/9/comments/3 - გადაიტანეთ მე-3 კომენტარი მე-9 პოსტზე.

თუ ობიექტზე მოქმედება არის CRUD ოპერაცია, ის შეიძლება გამოყენებულ იქნას როგორც შენახვის რესურსი:

• POST /api/posts/9/like - ნიშნავს No9 ჩანაწერს, როგორც მსგავსებას;
• DELETE /api/posts/9/like - წაშალეთ „კვალიფიცირებული“ ხატულა No9 პოსტიდან.

რესურსების შექმნასა და განახლებას შეუძლია რესურსის შემობრუნება

POST, PUT ან PATCH მეთოდებს შეუძლიათ შეცვალონ რესურსის ველები, რომლებიც არ იყო ჩართული შესვლამდე (მაგალითად, ID, შექმნის თარიღი ან განახლების თარიღი). იმისათვის, რომ არ გადაიტვირთოთ მომხმარებელი API-ით, თქვენ უნდა გააკეთოთ კიდევ ერთი მოთხოვნა განახლებული მონაცემების ამოღების მიზნით, ასეთ მეთოდებს შეუძლიათ მათი შემობრუნება.

გაფილტრეთ, დაალაგეთ და მოძებნეთ

ნებისმიერი HTTP შეკითხვის პარამეტრი შეიძლება გამოყენებულ იქნას ვიკიში მოთხოვნის გასარკვევად ან მონაცემების დასალაგებლად.

• GET /api/users?state=active – ანგარიშის აქტიური მომხმარებლების სია;
• GET /api/tasks?state=open&sort=priority,-created_at - შეუქმნელი ამოცანების სია, დალაგებული პრიორიტეტისა და შექმნის თარიღის მიხედვით (დაწყებული ახალი ამოცანიდან).

პლაკატის ნავიგაცია

თუ გსურთ დაამატოთ ინფორმაცია გვერდითი ნავიგაციის შესახებ სამიზნეების სიაში, შეგიძლიათ სწრაფად გამოიყენოთ HTTP Link სათაური, ვიდრე დაამატოთ მონაცემთა შეფუთვა.

სათაურის კონდახი:

Ბმული: ; rel = "შემდეგი", ; rel = "წინ", ; rel = "პირველი", ; rel = "ბოლო"

შესაძლო რელური მნიშვნელობები:

• შემდეგი - შედეგების გვერდი მოდის;
• წინა - შედეგების წინა მხარე;
• პირველი – შედეგების პირველი გვერდი;
• ბოლო - შედეგების ბოლო მხარე.

მნიშვნელოვანია ამ მნიშვნელობების გაგება, ვიდრე სხვადასხვა URL-ების აგება, რათა ზოგჯერ პოსტ-გვერდის ნავიგაცია ეფუძნებოდეს რთულ წესებს და არა გვერდების მარტივ ძიებას.

გადანაწილება HTTP მეთოდზე

ზოგიერთ სერვერთან ან კლიენტთან გამოსაყენებლად, რომლებიც არ უჭერენ მხარს HTTP მეთოდებს GET-ისა და POST-ის გარდა, შეიძლება საჭირო გახდეს მათი ემულაცია. მეთოდის მნიშვნელობები გადაეცემა X-HTTP-Method-Override-ის სათაურში და თავად მნიშვნელობა მონიშნულია როგორც POST მეთოდი. GET მოთხოვნა არ არის ბრალი სერვერის ბანაკის შეცვლაში!

Kodi HTTP სტატუსი

• 200 OK – პასუხი წარმატებულ მოთხოვნაზე GET, PUT, PATCH ან DELETE.
• 201 Created - POST პასუხი მიუთითებს ახალი ობიექტის შექმნის შედეგზე. პასუხს ასევე შეიძლება ახლდეს მდებარეობის სათაური, რომელიც მიუთითებს რესურსის URL-ზე.
• 204 No Content – ​​მიუთითებს ბრძანების წარმატებით დასრულებაზე, რომელიც არაფერს ცვლის (მაგალითად, DELETE).
• 404 არ მოიძებნა - მოთხოვნილი ობიექტი ვერ მოიძებნა.
• 500 შიდა სერვერის შეცდომა – შეცდომა სერვერზე.

შესყიდვების შემთხვევაში, ტიპს შეიძლება ჰქონდეს დამატებითი ინფორმაცია მყიდველებისთვის, თუ ეს შესაძლებელია.

მსახიობები ამბობენ:

„ცე API, რომელსაც ვიკირისტი HTTP ითხოვს

მიიღეთ, განათავსეთ, გამოაქვეყნეთі წაშლა ".

ვინც იგივე თქვა:

„რესურსების განაწილებისთვის იხილეთ დამატებითი URI“

სხვები ხმამაღლა ყვირის:

დასასრულს შეგიძლიათ თქვათ:

”პრინციპში, ეს მარტივია API, რა ვიკორისტი HTTPმართალია!"

ამ ადამიანების ქმედებებმა დაადასტურა შეწყალება,

დეიაკი ჩასტკოვო ვერნი,

მაგრამ აზრი არ აქვს,

ბო სტკივა ყველა აზრს კარგავს.

იმისათვის, რომ შესაძლებელი გახდეს RESTful API-ის შემუშავება,

პირველის მიხედვით

რა არის REST?

რა არის REST?

REST არის:

Virazno არა HTTP

ჩი არა პროტოკოლი

არანაირი სპეციფიკაცია

რატომ არის ამდენი REST API?

და მაინც...

REST არის არქიტექტურის სტილი.

ოჰ, ვაა... რა არის ეს სტილი არქიტექტურა?

არქიტექტურის სტილი

ბაჟანას არქიტექტურა

ეს არის უბრალოდ არქიტექტურა, პლუს საზღვრების ნაკრები, რომლებიც ქმნიან არქიტექტურას, რაც ქმნის საბოლოო არქიტექტურას.

ზასტოსოვიუჩი და ურთიერთდაკავშირება ეფუძნება ბაზილიკის არქიტექტურას, რომელიც ოპტიმიზებულია ვიკორისტანის მიწისქვეშა ჩანჩქერებისთვის.

REST ნიშნავს მონაცემთა გადაცემას

ეს ჩაიწერა როი ფილდინგმა თავის სადოქტორო დისერტაციაში 2000 წელს, სადაც აღწერს მიმდინარე ვებ არქიტექტურას, როგორც აბსტრაქციას.

ბულას სახელი ჰქვია ვიკლიკატის განცხადებას იმის შესახებ, თუ როგორ უნდა გაუმკლავდეთ ვებ დამატებების კარგ განვითარებას.

როიმ აღწერა REST მარტივი მაგალითით:

მოდით შევხედოთ ვებგვერდებს, როგორც ვირტუალურ მანქანას.

კანის მხარე წარმოადგენს სხეულს:

1. პირველ რიგში, კორისტუვაჩი აშორებს პირველ ბანაკს ინდექსის ბანაკის გარეგნობიდან.

2. შემდეგ გადადით პროგრამაში, აირჩიეთ შეტყობინება (აქ შეტყობინება იგზავნება გვერდზე)

3. ქორისტუვაჩევის ბანაკში შეტევის გადატანის შედეგი.

REST dosi და არა HTTP

რა თქმა უნდა, უკვე 2000 წელს, ქსელი უკვე მუშაობდა HTTP-ზე და როი და მისი კოლეგ ინჟინრები მასზე ბევრს მუშაობდნენ.

თუმცა, REST არ აკონკრეტებს სისტემის დანერგვის კონკრეტულ დეტალებს ან პროტოკოლის სინტაქსს.

სრულიად შესაძლებელია RESTful არქიტექტურის აშენება HTTP-ის ცნობილ პროტოკოლებზე.

მაგალითად, CoAP (Cooperative Access Protocol) არის RESTful პროტოკოლი მოწყობილობების განლაგებისთვის (ინტერნეტი ნივთები) და გამოიყენება მინიმალური რესურსების გასანაწილებლად როგორც მოწყობილობაზე, ასევე ერთდროულად.

რა აზრი აქვს REST-ის გამოყენებას?

მსოფლიო ქსელი დაფუძნებულია REST არქიტექტურაზე.

ამიტომ, თუ თქვენ შექმნით არა-RESTful API-ს, რომელიც გავრცელებულია ინტერნეტში, მაშინ თქვენ ქმნით არაოპტიმალურ სისტემას. არ არის ოპტიმალური ოპტიმიზებული არქიტექტურისთვის.

მნიშვნელოვანია აღინიშნოს, რომ ზოგიერთი არა-RESTful API შეიძლება არ იყოს ოპტიმალური ზღვარის არქიტექტურისთვის, მაგრამ არა ოპტიმალური სხვა პრობლემებისთვის. მაგალითად, თანამედროვე ფრონტ-ენდის პროგრამებს შეუძლიათ დააკმაყოფილონ ძალიან სპეციფიკური საჭიროებები და იზრდება მონაცემთა შეგროვების ბიბლიოთეკები, როგორიცაა GraphQL ან Falcor.

ასე რომ, რამდენი RESTful API არსებობს?

API არის RESTful, თუ ის მუდმივად მუშაობს REST საზღვრებში.

REST ნიშნავს 6 ზღვარს სისტემის სასურველი ოპტიმიზაციის მისაღწევად:

1. კლიენტ-სერვერი

ეს გაცვლა ეფუძნება ინტერესების პრინციპს.

ეს საშუალებას აძლევს კომპონენტებს დამოუკიდებლად განვითარდეს. როდესაც ჩვენ ვქმნით ჩვენს API-ს, ის მოქმედებს როგორც სერვერი, რომელიც ემსახურება კლიენტების დიდ რაოდენობას.

2. ნაყარის გარეშე

კლიენტსა და სერვერს შორის კავშირები უწყვეტია. ეს ნიშნავს, რომ კლიენტის პასუხისმგებლობაა შეიყვანოს სერვერზე ყველა საჭირო ინფორმაცია ტრანზაქციის დასასრულებლად.

ამ გაცვლის მთავარი უპირატესობა ის არის, რომ სისტემას შეუძლია უფრო სწრაფად მასშტაბირება, რადგან სერვერს არ სჭირდება კლიენტის დროის დაზოგვა მოთხოვნებს შორის. კლიენტის სისტემის შესახებ ინფორმაციის დამახსოვრების აუცილებლობა ათავისუფლებს სერვერის რესურსებს, რათა უფრო მეტი კლიენტი ერთდროულად მოემსახუროს.

ყველაზე ეფექტური ღონისძიება არის ის, რომელიც არ აძლიერებს ზომას.

თუ ჩვენ შევქმნით ჩვენს API-ს, ჩვენი ბრალი არ არის ქეშის იგნორირება.

4. სწორი ინტერფეისი

ქეშის ეფექტური ქეშირების უზრუნველსაყოფად, კომპონენტებს უნდა შეეძლოთ კომუნიკაცია ერთი ინტერფეისით. ერთი ინტერფეისით, სასურველი ინფორმაციის გადაცემა შესაძლებელია სტანდარტული ფორმით.

4.1. რესურსების იდენტიფიცირება

ეს ნიშნავს, რომ ნებისმიერი ინფორმაცია, რომლის დასახელებაც შესაძლებელია, შეიძლება იყოს რესურსი (სურათი, დოკუმენტი ან სხვა რესურსების ნაკრები)

4.2. რესურსებით მანიპულირება მანიფესტაციების საშუალებით

რესურსი შეიძლება წარმოდგენილი იყოს სხვადასხვა გზით.

მაგალითად, HTML, XML, JSON ან გაგზავნეთ JPEG ფაილი.

ეს ნიშნავს, რომ კლიენტები ურთიერთქმედებენ რესურსებთან მათი მანიფესტაციების საშუალებით, რაც მნიშვნელოვნად ამცირებს რესურსების აბსტრაქტულ გაგებას მათ ურთიერთქმედებაში.

4.3 მესამე, თვითაღწერილი ინფორმაცია

ეს ნიშნავს, რომ რესურსს შეუძლია აღწეროს მოხსენებული მოთხოვნა, ხოლო სერვერს შეუძლია მოგვაწოდოს აღწერილობები საიტის შესახებ. ამრიგად, HTTP სათაურები და პასუხების კოდები ამ წესის მთავარი განხორციელებაა.

4.4. ჰიპერმედია შეიძლება გახდეს ძრავა და გახდეს პროგრამა

ეს რეალურად ნიშნავს, რომ პროგრამა აღჭურვილია ძალაუფლებით, რაც საშუალებას აძლევს კლიენტებს რესურსებზე წვდომა ჰიპერ-ენერგიის საშუალებით.

როგორც ხედავთ, ბევრი წესის დანერგვა შესაძლებელია HTTP პროტოკოლში. ამიტომ, თუ Vikorist API სწორად იყენებს HTTP-ს, ეს შესანიშნავი შესაძლებლობაა გახდეთ RESTful.

5. ბაგატორული სისტემა

მდიდარ ქსელურ სისტემაში, შუამავლები, როგორიცაა პროქსი სერვერები, შეიძლება განთავსდეს კლიენტსა და სერვერს შორის, ერთი რეჟიმის ქსელის ინტერფეისის გამოყენებით.

მდიდარი სისტემის ერთ-ერთი უპირატესობა ის არის, რომ შუამავლებს შეუძლიათ კლიენტ-სერვერის ტრაფიკის ჩაჭრა სიმღერების მიზნებისთვის/მაგალითად, ქეშირების მიზნით.

6. ვიმოგას კოდი

ეს გაურთულებელი გაცვლა საშუალებას აძლევს კლიენტებს დააინსტალირონ პროგრამები კლიენტის მხარეს შესვლისთვის. ამის საუკეთესო მაგალითია JavaScript ინტერფეისის დანამატები. ეს შეიძლება ჩვენთვის დაუყოვნებლივ ცხადი იყოს, მაგრამ ინტერნეტის პირველ დღეებში იყო კონცეფცია, რომელიც ვითარდებოდა და ეს იყო ინტერნეტის არქიტექტურის ძირითადი ნაწილი.

მაშ, როგორ შევქმნათ REST API?

სწორად ვიკორისტუვა HTTP

თუ გსურთ RESTful API, შეცვალეთ RESTful პროტოკოლი. ინტერნეტისთვის, HTTP პროტოკოლი არის პირველი არჩევანი. შექმენით API HTTP სათანადო გამოყენებისთვის.

შექმენით ერთი ინტერფეისი

გააერთიანეთ თქვენი ცნებები რესურსებთან და მიანიჭეთ უნიკალური იდენტიფიკატორები თითოეულ მათგანს. უმარტივესი გზა იქნება უცხოელებისთვის მონაცემთა ბაზის სერვისის გამოყენება. ასეთი სერვისისთვის შეგვიძლია დავასახელოთ ორი რესურსი; კორისტუვაჩივი და კორისტუვაჩივი (საკოლექციო რესურსი). ამ რესურსების იდენტიფიცირება შესაძლებელია თქვენი API-ის /users URI-ით და /user/(id) URI-ით.

აჩვენეთ თქვენი API ჰიპერძლევა

გახსოვდეთ REST არქიტექტურა

RESTful API-ს შექმნის ნაკლებად რთული ასპექტი დამოკიდებულია იმაზე, თუ რამდენად მნიშვნელოვანია ინტერნეტისა და მისი ძირითადი არქიტექტურის გაგება. ჩვენ შეგვიძლია დავაჩქაროთ ეს ოპტიმიზაცია, ან შეგვიძლია უგულებელვყოთ იგი.

თუ თქვენ გაქვთ რაიმე პრობლემა კვების შესახებ, ჩვენ ვითხოვთ ჩვენს

გმადლობთ, რომ წაიკითხეთ ჩემი პოსტი.
საპასუხო რეაქცია და აზრები ყოველთვის ტრიალებს კომენტარების განყოფილებაში.

გამარჯობა, ძვირფასო მკითხველებო! სანამ ამ სტატიის კითხვას დაიწყებდეთ, მსურს აღვწერო ამ შემოქმედებისა და გამოცხადების მიზნები, რამაც მიბიძგა დამეწერა.

ჩვენი კომპანიის ერთ-ერთ პროექტზე, ვინილზე, საჭირო გახდა სერვერის აპლიკაციის დიზაინი REST სტილში. თავიდანვე გვაინტერესებდა, რა უნდა გაგვეკეთებინა მარტივ ამოცანასთან და ამ მიზნით ამოგვეღო ყველაზე ძლიერი ინფორმაცია.

მას შემდეგ რაც დავიწყეთ არქიტექტურის შემუშავებისა და REST სერვისების ერთიან სტილში მიყვანის პროცესი, მე და ჩვენს კოლეგებს დავიწყეთ ურთიერთგამომრიცხავი საკითხები და განსხვავებული თვალსაზრისი ამა თუ იმ ასპექტის განხორციელებაზე. აქ ჩვენ მივხვდით, რომ აუცილებელია Google-ის გახსნა და კოლექტიური გონების დასახმარებლად, ვისწავლოთ საუკეთესო პრაქტიკა, რომელიც თავიდან უნდა იქნას აცილებული RESTful პროგრამების შემუშავებისას.

ეს სტატია საინტერესო იქნება იმ ადამიანებისთვის, რომლებსაც უკვე აქვთ მკაფიო გაგება ვებ დანამატებთან (და შესაძლოა REST სერვისებთან) მუშაობის შესახებ, მაგრამ არ მოითხოვენ მათი ცოდნის კონსოლიდაციას და სტანდარტიზაციას.

ვიზნაჩენნია

დასაწყისისთვის, თქვენ უნდა გაარკვიოთ რა არის REST. ვიკიპედია იძლევა ამ კვებით პასუხს. დასვენება (წარმომადგენლობითი სახელმწიფო ტრანსფერი- "გადატანა მანიფესტაციაში") არის საზღვრის შიგნით გაყოფილი დანამატის კომპონენტებს შორის ურთიერთქმედების არქიტექტურული სტილი. REST უზრუნველყოფს კავშირების მოსახერხებელ კომპლექტს, რომელიც გასათვალისწინებელია განაწილებული ჰიპერმედიის სისტემის შექმნისას.

ჩემი სიტყვებით, მე ავხსენი REST-ის კონცეფცია, როგორც „რეკომენდაციების ნაკრები, რომელიც საშუალებას გაძლევთ გააერთიანოთ ურთიერთქმედება კლიენტსა და სერვერის აპლიკაციებს შორის“.
ამ სტატიაში შევეცდები მოგაწოდოთ ინფორმაცია ამ „რეკომენდაციების“ შესახებ, რომლებიც დაგეხმარებათ შექმნათ და შექმნათ REST სერვისები ზოგადად მიღებული პრაქტიკის შესაბამისად.

ასევე გესმოდეთ, რომ ეს არის REST სერვისი. მე განვსაზღვრე REST სერვისი, როგორც "კლიენტის პროგრამასა და სერვერს შორის ურთიერთქმედების წერტილი". ჯავის ტერმინოლოგიაში ეს არის სერვლეტი, რომელსაც კლიენტი აგზავნის მოთხოვნას.

საკითხები

სანამ წესების აღწერას დავიწყებდეთ, მინდა გადმოგცეთ აზრი, რომ REST არ არის სტანდარტი, რადგან არ არსებობს ერთიანი წესები, რომელთა დაცვაც საჭიროა. ეს ნიშნავს, რომ ჯერ კიდევ არ არის უფრო დიდი გაგება იმ გადაწყვეტილებების შესახებ, რომლებსაც შეუძლიათ ამა თუ იმ სიტუაციის საუკეთესო გადაჭრა. ძალიან ხშირია იმის წაკითხვა, თუ რა HTTP მეთოდების გამოყენება და რა HTTP კოდის გამოყენება თითოეულ კონკრეტულ სიტუაციაში.

სერვისის სახელი

დასაწყებად, თქვენ უნდა აირჩიოთ სახელი REST სერვისისთვის. სერვისის სახელით, მე პატივს ვცემ თქვენს გზას მოთხოვნის URI-ში. Მაგალითად, http://my-site.by/api/rest/service/name. სახელის ასარჩევად, ჩვენ უნდა გვესმოდეს, რა არის „რესურსები“ REST არქიტექტურაში.

რესურსზე წარდგენა

REST ტერმინოლოგიაში ეს შეიძლება იყოს რესურსი - HTML დოკუმენტი, სურათები, ინფორმაცია კონკრეტული კლიენტის შესახებ და ა.შ. ვინაიდან რესურსი რეალური ობიექტია, მისი დანახვა მარტივია სტანდარტულ ფორმატში, მაგალითად, XML ან JSON. შემდეგ სერვერს შეუძლია ამ რესურსის გაგზავნა არჩეული ფორმატის გამოყენებით, ხოლო კლიენტს შეუძლია იმუშაოს რესურსთან სერვერიდან შერჩეული ფორმატის გამოყენებით.

"პროფილის" რესურსზე გაგზავნილი მაგალითი JSON ფორმატში:

"id" :1,

"სახელი": "მაჰეშ",

"login" :"manesh"

REST არ აწესებს რაიმე აშკარა შეზღუდვას იმ ფორმატზე, რომელიც გამოყენებული იქნება რესურსების წარმოსაჩენად, და არსებობს რამდენიმე წესი, რომლებიც უნდა დაიცვან ფორმატის შემუშავებისას, რომელიც გამოყენებული იქნება რესურსების წარმოსაჩენად:

• კლიენტი და სერვერი პასუხისმგებელნი არიან არჩეული ფორმატის გაგებაზე და მუშაობის შესაძლებლობაზე.
• რესურსის სრულად აღწერა შესაძლებელია ნებისმიერ არჩეულ ფორმატში, რესურსის სირთულის მიუხედავად.
• ფორმატს შეუძლია გადმოგცეთ რესურსებს შორის კავშირის დამყარების შესაძლებლობა.

რესურსის „მოთხოვნის“ წარდგენის მაგალითი და რესურსის „პროფილთან“ კავშირი:

ID: 11254,

ვალუტა: "ევრო",

თანხა: 100

პროფილი: (

ID: 11,

uri: "http://MyService/Profiles/11"

როგორც ხედავთ, არ არის სავალდებულო რესურსის მთელი სტრუქტურის დუბლირება, რომელიც მინიჭებულია სხვა რესურსზე. Natomist შეიძლება იყოს vikoristovvat უფრო ჭკვიანურად გაგზავნილი სხვა რესურსი.

Zvernennya რესურსს

კანის რესურსი შეიძლება ცალსახად იყოს იდენტიფიცირებული მუდმივი იდენტიფიკატორით. „მუდმივი“ ნიშნავს, რომ იდენტიფიკატორი არ იცვლება მონაცემთა გაცვლის საათის განმავლობაში და როცა შეიცვლება, ის მიეკუთვნება რესურსს. თუ რესურსს ენიჭება სხვა იდენტიფიკატორი, სერვერი ვალდებულია აცნობოს კლიენტს, რომელიც შემდეგ მიუთითებს ახალ მისამართზე გაგზავნის თარიღს. რესურსი ცალსახად იდენტიფიცირებულია URL-ით. ეს ნიშნავს, რომ URL არის ძირითადი გასაღები მონაცემთა ელემენტისთვის. ტოტო, მაგალითად, კიდევ ერთი წიგნი წიგნიდან პოლიციის მატიმა ჩანდა /წიგნები/2 და ამ წიგნის 41-ე მხარეა /წიგნები/2/გვერდები/41 . Zvіdsi y ამოცანების ფორმატი. უფრო მეტიც, საერთოდ არ აქვს მნიშვნელობა, რომელი ფორმატი შეიცავს მისამართს მიღმა არსებულ მონაცემებს /წიგნები/2/გვერდები/41 – ეს შეიძლება იყოს HTML, jpeg ფაილის სკანირებული ასლი ან Word დოკუმენტი.

რეკომენდირებულია აირჩიოთ მრავალი რესურსის სახელი REST სერვისისთვის სახელის მინიჭებისას. ეს მიდგომა საშუალებას გაძლევთ დაამატოთ ახალი REST სერვისები არსებულის სახელების გაფართოების გარეშე. მაგალითად, მომსახურება /წიგნები მოგვეცით ყველა თქვენი წიგნის სია, /წიგნები/3 მიმართეთ ინფორმაციას მე-3 წიგნისა და სერვისის შესახებ /წიგნები/3/გვერდი გადაატრიალეთ მესამე წიგნის ყველა მხარე.

სერვისებისთვის, რომლებიც ქმნიან კონკრეტულ მოქმედებებს რესურსზე, მოქმედებების შეყვანის ორი მიდგომა არსებობს: სერვისის სახელში ან მის პარამეტრებში. Მაგალითად, /წიგნები/3/სუფთა ან /წიგნები/3?სუფთა . უპირატესობას პირველ ვარიანტს ვაძლევ, რადგან ასეთი სერვისები ხშირად იყენებენ POST მეთოდებს, რომლებიც არ უჭერენ მხარს URL-ზე პარამეტრების გადაცემას, რაც სერვისს, ჩემი აზრით, არც თუ ისე იკითხავს. სერვისის სახელწოდების მოქმედების სახეობიდან გამომდინარე, ჩვენ უფრო გავაფართოვებთ ჩვენს სერვისს, რაც შეიძლება მეტი დამოკიდებულია HTTP მეთოდის ტიპზე.

ასევე არ არის რეკომენდებული სახელების გამოყენება, რომლებიც შეიცავს ტეგს მარცხნივ და აღწერს საწყობის სერვისის ბიზნესს (როგორც რეკომენდირებულია მუშაობა java მეთოდების დასახელებისას). მაგალითად, zamіst /getAllCars ფულის შოვნის უკეთესი გზა / მანქანები . ვინაიდან მეთოდის ერთი სიტყვით აღწერა შეუძლებელია, აუცილებელია გამყოფების ერთი სტილის ჩამოყალიბება, მე ვიკორს ვუწოდებ "-", რომელიც ყველაზე პოპულარული მიდგომაა. Მაგალითად, /მანქანები/3/შეიძლება გაყიდვა.

დამატებითი დეტალები REST სერვისების სახელების დიზაინის შესახებ შეგიძლიათ წაიკითხოთ აქ

HTTP მეთოდი

REST-ს აქვს 4 ძირითადი HTTP მეთოდი: GET, POST, PUT, DELETE. ყველაზე ხშირად, მეთოდების კანი ემსახურება CRUD-ით ბიზნესის დასრულებამდე ( გგამეორება, რწადი, uთარიღი, დ elete - "შექმნა, კითხვა, განახლება, ნახვა").
POST – შექმნა, GET – წაკითხვა, PUT – განახლება, DELETE – წაშლა.

მნიშვნელოვანი დამატება: მათ უწოდებენ REST- Patterns, რომლებიც დაკავშირებულია HTTP მეთოდებთან, რომლებიც უნდა განხორციელდეს. სახლთან უფრო ახლოს, სხვადასხვა მოდელები სხვადასხვანაირად უყურებენ POST-ს და PUT-ს. თუმცა, შექმნის, ჩანაცვლების ან განახლებისთვის PUT დავალებები არ არის მინიჭებული POST-ისთვის. ამრიგად, POST და PUT კოდები შეიძლება შეიცვალოს. უმეტეს შემთხვევაში, POST გამოიყენება შესაქმნელად, ხოლო PUT გამოიყენება რედაქტირებისთვის და რატომაც ცოტა მოგვიანებით აგიხსნით.

მე მოგცემთ რესურსებთან ურთიერთქმედების სხვადასხვა მეთოდის მაგალითებს.

• მიიღეთ /წიგნები/- ირჩევს ყველა წიგნის სიას. პატიებისკენ მოუწოდე, ესე იგი. მოათავსეთ მხოლოდ იდენტიფიკატორის და ობიექტის სახელის ველები, სხვა მონაცემების გარეშე.
• მიიღეთ /წიგნები/(ID)- წიგნის შესახებ მეტი ინფორმაციის წაშლა.
• პოსტი /წიგნები/- ახალ წიგნს ვქმნი. მონაცემები გადაეცემა შენიშვნაში.
  PUT /წიგნები/(ID)– ცვლის წიგნის მონაცემებს იდენტიფიკატორით (id), შესაძლოა ჩაანაცვლოს ისინი. მონაცემები ასევე გადაეცემა მოთხოვნით.
• OPTIONS /წიგნები- ირჩევს მხარდაჭერილი ოპერაციების სიას მინიჭებული რესურსისთვის (პრაქტიკულად არ არის გაფორმებული)
• წაშლა /წიგნები/(id)– წაშლის მონაცემებს იდენტიფიკატორიდან (id).

უსაფრთხოება და უძლურება

ის ასევე დაგეხმარებათ აირჩიოთ HTTP მეთოდი, რათა იცოდეთ ამ მეთოდების უსაფრთხოება და უძლურება.

უყურადღებო მოთხოვნა არ არის მოთხოვნა, რომელიც არ ცვლის პროგრამის სტატუსს.

იდემპოტენტური მოთხოვნა არ არის მოთხოვნა, რომლის ეფექტი არის მრავალსაპასუხო დერივაცია უფრო ძველია, ვიდრე ერთჯერადი დერივაციის ეფექტი.

ამ ცხრილის მიხედვით თუ ვიმსჯელებთ, GET მოთხოვნა არ ცვლის რესურსის სტაგნაციას. PUT და DELETE განცხადებებს შეუძლია შეცვალოს რესურსის სტატუსი, მაგრამ მათი მშვიდად განმეორება შესაძლებელია, რადგან არ არსებობს მიზეზი, რომ წინა განცხადება დასრულდა. პრინციპში, ლოგიკურია: თუ თქვენ განმეორებით გაიმეორებთ კონკრეტულ რესურსს და შეცვლით მას მოცემული რესურსით, შედეგი იქნება რესურსის შემდგომი ჩანაცვლება. Ale POST იწერება, როგორც ცხრილში ჩანს, არ არის უსაფრთხო და უძლური. ის არა მხოლოდ ცვლის რესურსს, არამედ ის ეფექტიც, რომელიც ხშირად მეორდება, ძალიან ცვალებადია. ამის ნაცვლად, ეს წარმოდგენილია ახალი DB ელემენტების დამატების ოპერაციით: ფანჯარაში იწერება X ჯერ, ხოლო DB-მა მიიღო X ელემენტები.

მე ასევე აღვნიშნავ, რატომ არ არის დამნაშავე GET მოთხოვნები რესურსის სტატუსის შეცვლაში. GET მოთხოვნები შეიძლება იყოს ქეშირებული, მაგალითად, პროქსი სერვერზე. ამ შემთხვევაში, მოთხოვნა შეიძლება არ მიაღწიოს სერვერს პროგრამის მიერ, არამედ იმიტომ, რომ პროქსი სერვერი აბრუნებს ინფორმაციას ქეშიდან.

HTTP კოდი

HTTP სტანდარტი აღწერს 70-ზე მეტ სტატუსის კოდს. კარგ ფორმაში, მთავარი მინდა.

• 200 – OK – წარმატებული მოთხოვნა. თუ კლიენტმა მოითხოვა რაიმე მონაცემი, ის გამოჩნდება სათაურში ან/და ინფორმაციას.
• 201 – OK – წარმატებული ქვესტის შედეგად შეიქმნა ახალი რესურსი.
• 204 – OK – რესურსი წარმატებით იქნა შეძენილი.
• 304 – არ არის შეცვლილი – კლიენტს შეუძლია ქეშიდან მონაცემების წვდომა.
• 400 – ცუდი მოთხოვნა – მოთხოვნა არასწორია ან მოთხოვნის დამუშავება შეუძლებელია.
• 401 – არაავტორიზებული – მოთხოვნა მიუთითებს მომხმარებლის ავთენტიფიკაციაზე.
• 403 – აკრძალულია – სერვერმა მოითხოვა ნებართვა, მაგრამ არ აქვს მისი დამუშავების უფლება და წვდომა დაბლოკილია.
• 404 – ვერ მოიძებნა – რესურსი ვერ მოიძებნა.
• 500 – შიდა სერვერის შეცდომა – API დეველოპერები არიან დამნაშავეები ასეთი შეცდომების თავიდან აცილებაში.

ეს სარგებელი შეიძლება დაიჭიროთ გლობალური დაჭერის ბლოკიდან, დაგირავდეთ ან სხვაგვარად დაბრუნდეთ ფილიალიდან.

რაც უფრო დიდი იქნება კოდების ნაკრები, რომელსაც ჩვენ ვიკორიზებთ, მით უფრო ინტელექტუალური იქნება ჩვენს მიერ შექმნილი API. თუმცა, გაითვალისწინეთ, რომ ბრაუზერები ამ კოდებს განსხვავებულად ამუშავებენ. მაგალითად, ზოგიერთი ბრაუზერი, რომელიც უარყოფს 307 საპასუხო კოდს, დაუყოვნებლივ აჩვენებს გადამისამართებას, ზოგი კი საშუალებას გაძლევთ გაუმკლავდეთ ამ სიტუაციას და შეინახოთ მოქმედება. უპირველეს ყოვლისა, მნიშვნელოვანია გვესმოდეს, თუ როგორ მუშაობს ეს კლიენტის მხარეს!

სათაურები

• Შინაარსის ტიპი- მოთხოვნილი ფორმატი;
• მიღება- სამაუწყებლო ფორმატების სია.

რესურსების ძიების პარამეტრები

იმისათვის, რომ გამარტივდეს იმ სერვისების შერჩევა, რომლებიც პასუხისმგებელნი არიან ნებისმიერი ინფორმაციის დამუშავებაზე და ასევე გახადონ ისინი უფრო პროდუქტიული, აუცილებელია იმის გაგება, თუ როგორ უნდა შეიყვანოთ პარამეტრების დახარისხება, ფილტრაცია და ა.შ. ველების ტყე და პაგინაცია.

ფილტრაცია

შექმენით უნიკალური პარამეტრი კანის ველისთვის ფილტრაციისთვის. ეს საშუალებას გაძლევთ შეზღუდოთ გამომავალი ინფორმაციის რაოდენობა, რაც ოპტიმიზებს მოთხოვნის დამუშავების დროს.

მაგალითად, ყველა წითელი წიგნის საჩვენებლად, თქვენ უნდა დაწეროთ:

მიიღეთ /წიგნები? ფერი=წითელი

სორტუვანია

დახარისხება ხორციელდება ფილტრაციის ანალოგიურად. მაგალითად, გამოცემის თარიღის და სათაურის მიხედვით დალაგებული ყველა წიგნის საჩვენებლად, თქვენ უნდა შეიყვანოთ შემდეგი ჩანაწერი:

მიიღეთ /წიგნები?დახარისხება=-წელი,+სახელი

პაგირება

რესურსების სიაზე წვდომის მხარდასაჭერად, რომლებიც შეიძლება გამოჩნდეს პროგრამის იმავე გვერდზე, REST API იყენებს პაგინაციის ფუნქციას. იგი ხორციელდება ჩვენთვის ცნობილი SQL პარამეტრების გამოყენებით: ლიმიტი და ოფსეტური. Მაგალითად:

მიიღეთ /წიგნები?offset=10&limit=5

გარდა ამისა, კარგია შეტყობინების ჩვენება წინა, უკანა, პირველ და დანარჩენ გვერდებზე Link header-ში. Მაგალითად:

Ბმული: ; rel = "შემდეგი",
; rel = "ბოლო",
; rel = "პირველი",
; rel = "წინ"

აირჩიეთ ველები რესურსისთვის

მექანიკური სერვისისთვის, ტრაფიკის დაზოგვის მიზნით, შეგიძლიათ დაამატოთ მონაცემთა ჩვენების ფორმატის მორგების შესაძლებლობა. შესაძლებელია რესურსისთვის ველების არჩევა, რამაც შესაძლოა განაახლოს REST სერვისი. მაგალითად, თუ თქვენ გჭირდებათ წიგნის ორივე ID და მათი ფერების ამოღება, უნდა შეიყვანოთ შემდეგი ჩანაწერი:

GET /books?fields=id,color

მე გიშველი

RESTful სერვისების გაცვლის ერთ-ერთი მიზეზი არის ის, რომ მათ უნდა დაზოგონ კლიენტის დრო, რათა მოხსნან მოთხოვნები.

მაგალითი სერვისისთვის, რომელიც არ ზოგავს ფულს:
მოთხოვნა 1:
მოთხოვნა 2: მიიღეთ http://MyService/Persons/2 HTTP/1.1

ამ სასმელების კანს შეიძლება განუვითარდეს კანის პრობლემები, განურჩევლად მეორისა.

სერვისის მაგალითი, რომელიც დაზოგავს ფულს:
მოთხოვნა 1: მიიღეთ http://MyService/Persons/1 HTTP/1.1
მოთხოვნა 2: მიიღეთ http://MyService/NextPerson HTTP/1.1

სხვა მოთხოვნის დასამუშავებლად, სერვერმა უნდა „დაიმახსოვროს“ დარჩენილი პირის ID, რომელიც მოითხოვა კლიენტმა. ტობტო. სერვერი პასუხისმგებელია მისი წარმოების ხაზის „დამახსოვრებაზე“, წინააღმდეგ შემთხვევაში სხვა მიწოდებამ შეიძლება გამოიწვიოს პრობლემები. სერვისის დაპროექტებისას არ არის საჭირო ენერგიის დაზოგვა, რაც დაბალ პრიორიტეტს ტოვებს.

სერვისის უპირატესობები, რომელიც არ დაზოგავს ხარჯებს:

• სამსახური ერთმანეთისგან დამოუკიდებლად ითხოვს სასმელს;
• სამსახურის არქიტექტურა დაემშვიდობება;
• დამატებითი ძალისხმევა არ არის საჭირო სერვისების განსახორციელებლად HTTP პროტოკოლის გამოყენებით, რომელიც ასევე არ ინახავს მონაცემებს.

არ არის საკმარისი სერვისი, რომელიც არ დაზოგავს ფულს:

• კლიენტი თავად არის პასუხისმგებელი კონტექსტში საჭირო სერვისის სერვისზე გადატანაზე.

ვერსია

კარგი პრაქტიკაა REST API ვერსიის მხარდაჭერა. ეს საშუალებას გაძლევთ მარტივად გააფართოვოთ API ისე, რომ არ დაავალდებულოთ კლიენტები, რომლებიც მას უკვე იყენებენ, განახორციელონ ცვლილებები.
ვერსიების განხორციელების რამდენიმე მიდგომა:

• შემდგომი დახმარებისთვის მიიღეთ სათაური. ამ შემთხვევაში, API ვერსია მითითებულია Accept -ში. Accept:text/v2+json
• Z wikiristannyam URI. ამ მიდგომით, API ვერსია მითითებულია პირდაპირ URI-ში - http://localhost/api/v2/books
• მორგებული სათაურის ვიკი. შეგიძლიათ გამოიყენოთ power header, რომელიც ასევე პასუხისმგებელია API ვერსიის გავლაზე - API-ვერსია:v2
• მოთხოვნილია Vikoristannya პარამეტრი. შეგიძლიათ გამოიყენოთ API ვერსიის გადაცემის პარამეტრი - /წიგნები?v=2

თითოეულ წარმოდგენილ მეთოდს აქვს ძილის უფლება, თითოეულს აქვს თავისი დადებითი და უარყოფითი მხარეები. თუმცა, თქვენი გადასაწყვეტია, ვერსიის კონტროლის განხორციელების რომელი მეთოდი მოერგება თქვენს პროექტს.

დოკუმენტაცია

ჩვენი REST სერვისების ხელით კონფიგურაციისთვის, თქვენ უნდა შექმნათ კარგი და ყოვლისმომცველი დოკუმენტაცია. ამისთვის შეგიძლიათ გამოიყენოთ სხვადასხვა ხელსაწყოები, მაგალითად, Mashape ან Apiary, მაგრამ გირჩევთ გამოიყენოთ Swagger.

Swagger არის ტექნოლოგია, რომელიც საშუალებას გაძლევთ დოკუმენტურად დააფიქსიროთ REST სერვისები. Swagger ხელს უწყობს უსახო პროგრამირებას და ჩარჩოებს. Plus Swagger გთავაზობთ ინტერფეისს დოკუმენტაციის განსახილველად.

თქვენ შეგიძლიათ ნახოთ ანგარიშის ინფორმაცია Swagger-ის შესახებ ფასისთვის.

არქივი

კეშუვანია

ასევე, მონაცემთა ბაზაში მოთხოვნების დასაჩქარებლად და ჩვენი REST სერვისებისთვის მონაცემთა სიჩქარის გასაზრდელად, რეკომენდებულია ქეშირების მექანიზმის დაყენება. ქეშირების რეგულირება შესაძლებელია როგორც სერვერის დონეზე, ასევე, გარდა ამისა, სიტუაციიდან გამომდინარე.

Keshuvannyam-ს შეუძლია გამოიყენოს შემდეგი HTTP სათაურები:

• თარიღი - რესურსის შექმნის თარიღი და საათი.
• ბოლო ცვლილება – სერვერზე რესურსის ბოლო ცვლილების თარიღი და საათი.
• Cache-Control არის HTTP 1.1 სათაური, რომელიც გამოიყენება ქეშის გასაკონტროლებლად.
• ასაკი - რესურსის დარჩენილი დაჭერის მომენტიდან ერთი საათის შემდეგ, სათაური შეიძლება დაემატოს შუალედურ (კლიენტსა და სერვერს შორის) კომპონენტით (მაგალითად, პროქსი სერვერი)