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