სიახლეები და ანალიზი
შემდეგ ინტეგრაციამდე: ვინ არის პასუხისმგებელი API-სა და მის გარემოებზე?
Postman-ის ორი სტატია API ინვენტარს წვდომის პოლიტიკას უკავშირებს. კატალოგი ინტეგრაციის გადაწყვეტილებებს უნდა ემსახურებოდეს და არა მხოლოდ მისამართების სია იყოს.
კომპანია კიდევ ერთ ინტეგრაციას ამატებს, მაგრამ ვერავინ ადგენს სწრაფად API-ის პასუხისმგებელს, მიმდინარე კონტრაქტსა და საწარმოო მისამართს. ეს დოკუმენტაციის მოუხერხებლობაზე მეტია. კონტექსტის გარეშე რთულია ინციდენტის პასუხისმგებელზე გადაცემა ან ახალი აპლიკაციის წვდომის განსაზღვრა. Postman-ის ოქტომბრის ორი სტატია სერვისების ინვენტარს მათი გამოყენების კონტროლთან აკავშირებს.
კატალოგმა სერვისის მდგომარეობა უნდა ახსნას
1 ოქტომბრის API Catalog გზამკვლევში Postman ინფორმაციის ოთხ ჯგუფს აერთიანებს: პასუხისმგებლობა და აღმოჩენა, სპეციფიკაციის ხარისხი, CI და საწარმოო გარემოს მდგომარეობა. ბოლო ჯგუფი endpoint-ების მეტრიკებსაც მოიცავს. ეს სიგნალები დაკავშირებული წყაროებიდან მოდის; მხოლოდ კატალოგის არსებობა ინფორმაციის სიახლეს არ ადასტურებს.
გუნდისთვის ეს კითხვას აჩენს, რას ნიშნავს სინამდვილეში „API მუშაობს“. staging endpoint-მა შეიძლება წარმატებით უპასუხოს, მაშინ როცა production შეცდომებს აბრუნებს. სასარგებლო ჩანაწერი გარემოებს განასხვავებს და სიგნალების წყაროს აჩვენებს. წყაროს გათიშვისას ძველი მწვანე სტატუსი ახალ შემოწმებად არ უნდა გამოიყურებოდეს.
ბიზნესის პასუხისმგებელს მოქმედებისთვის გამოსადეგი ინფორმაცია სჭირდება: ვინ აგებს პასუხს, რომელი სამუშაო პროცესი არის სერვისზე დამოკიდებული და როგორ უნდა გამოიძიონ პრობლემა. ამ კავშირების გარეშე მისამართების სია შეიძლება კიდევ ერთ ცნობარად იქცეს, რომელსაც ინციდენტისას არავინ იყენებს.
API ინვენტარისა და მართვადი წვდომის კონცეპტუალური AI ილუსტრაცია.
პოლიტიკას ამოცნობადი რესურსები სჭირდება
6 ოქტომბრის Passport-ის აღწერაში Postman საკუთარ გზას აღწერს ინვენტარიდან პოლიტიკამდე და მის აღსრულებამდე. წვდომა გამომძახებლის ვინაობასა და კონკრეტულ endpoint-ებს უკავშირდება, საწყისი საიდენტიფიკაციო მონაცემის გავრცელების ნაცვლად. ეს მომწოდებლის გამოცდილებაა და არა გარანტია ყველა სისტემისთვის.
შედარება მიანიშნებს, რომ ფართო წვდომას სასარგებლო ინვენტარი უნდა უსწრებდეს. დაადგინეთ, რა არსებობს და ვინ არის პასუხისმგებელი, შემდეგ განსაზღვრეთ ახალი მომხმარებლის დასაშვები მოქმედებები. დახვეწილი კატალოგი აღსრულებადი პოლიტიკის გარეშე წვდომას ვერ აკონტროლებს. პოლიტიკა ამოცნობადი რესურსების გარეშე გაურკვეველ საზღვრებს ტოვებს.
დაიწყეთ ერთი საოპერაციო გადაცემით
აირჩიეთ ინტეგრაცია, რომელიც შეკვეთას ქმნის ან დოკუმენტს გადასცემს. ჩაიწერეთ პასუხისმგებელი, კონტრაქტი, staging და production გარემოები, მომხმარებელი სისტემები და ჩავარდნის შედეგები. გუნდს სთხოვეთ აჩვენოს მიმდინარე ტესტირების ინფორმაციის წყარო. შემდეგ დაამატეთ საცდელი მომხმარებელი განზრახ შეზღუდული ოპერაციებით.
შეამოწმეთ ზედმეტი მოქმედების უარყოფა და პრობლემის პასუხისმგებელთან გადაცემის გზა. კონტრაქტის ცვლილების შემდეგ გადაამოწმეთ, რომ სერვისის ჩანაწერიც განახლდა. ეს უფრო სასარგებლოა, ვიდრე კატალოგის „ყოველთვის განახლებულად“ გამოცხადება მისი კავშირების გამოცდის გარეშე.
ჩვენი ბიზნესწესების გზამკვლევი დასაშვები მოქმედებების განსაზღვრაში დაგეხმარებათ. საარქივო API არქიტექტურა კონტრაქტებსა და წვდომას ცალკე მოთხოვნებად განიხილავს. ახალ API ინტეგრაციამდე განვიხილოთ პასუხისმგებლები, გარემოები და მომხმარებელი სისტემები, ნაცვლად წვდომების დარიგებით დაწყებისა.