ინდივიდუალური API დაკავშირებული აპლიკაციებისთვის

საერთო წესები სხვადასხვა აპლიკაციისთვის

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

მოდელები, მარშრუტები და წვდომა

მონახაზში იყო Node.js, Express ან Fastify, რელაციური MariaDB და მოდელებისთვის Sequelize. მარშრუტებს, კონტროლერებს, მოდელებსა და middleware-ს განსხვავებული პასუხისმგებლობა ჰქონდა. Redis ხშირი მოთხოვნის ქეშის ვარიანტი იყო. მოთხოვნის ოპტიმიზაცია და SQL ინექციის დაცვა აუცილებელ მოთხოვნებად იყო მითითებული.

ავთენტიფიკაციაში განიხილებოდა JWT ან OAuth 2.0; შესრულების მონახაზში JWT middleware და bcrypt პაროლის ჰეში. როლები, TLS და მოთხოვნების ლიმიტები დიზაინის ნაწილი იყო. ქეშის ვადასა და თითოეული პასუხის ნახვის უფლებას განხორციელებამდე განსაზღვრა სჭირდება.

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

Swagger ან Postman აღწერდა მისამართებს, მოთხოვნა-პასუხის მაგალითებსა და შეცდომებს. ცენტრალური ჟურნალი და შეცდომის middleware ჩავარდნას გასაგებს გახდიდა. ერთეულისა და ინტეგრაციის ტესტები, გამოშვების პროცესთან ერთად, მოცულობაში შედიოდა.

ეს არქიტექტურის მონახაზია; არც დატვირთვის მაჩვენებელს ადასტურებს და არც ერთდროულად REST-ისა და GraphQL-ის მიწოდებას. ახალ API-ში მისამართებამდე რესურსი, უფლება და შეცდომის ქცევა განისაზღვრება.

იხილეთ API ინტეგრაციები, აპლიკაციები, ინფრასტრუქტურა. აღწერეთ API-ის მომხმარებელი სისტემები.

თავდაპირველი დავალება

წყარო API-ის მოთხოვნები და არქიტექტურის მონახაზია. საბოლოო დანერგვა, მიმდინარე მუშაობა და გაზომილი შედეგები ჯერ დასადასტურებელია.