API და სისტემების ინტეგრაცია
ჩვენ ვქმნით API-ებს, რომლებზეც სხვა გუნდებს შეუძლიათ მშვიდად დააშენონ ფუნქციონალი, და ვაკავშირებთ სისტემებს, რომლებიც თავდაპირველად ერთმანეთთან სასაუბროდ არ იყო გათვლილი. გადახდები, შეტყობინებები, გარე სერვისები და მონაცემთა სინქრონიზაცია, გათვლილი იმ დღეებზეც, როდესაც რომელიმე მხარეს შეფერხებაა.
რას ვაკეთებთ
- REST API დაპროექტება ვერსიონირებით, გვერდებად დაყოფით (pagination) და კოდთან ერთად განახლებადი დოკუმენტაციით.
- გადახდების ინტეგრაცია: ტრანზაქციები, გამოწერები, თანხის დაბრუნება (refunds) და ანგარიშსწორების შეჯერება.
- შეტყობინებები და რიგები RabbitMQ-ით იმ ამოცანებისთვის, რომლებიც არ უნდა სრულდებოდეს მოთხოვნის პროცესში.
- გარე სერვისების ინტეგრაცია: CRM სისტემები, ბუღალტერია, ლოჯისტიკა და იდენტიფიკაციის პროვაიდერები.
- Webhook-ები და გეგმური სინქრონიზაცია გამეორებადობის დაცვით (idempotency), ავტომატური განმეორებებითა და აუდიტის ლოგით.
როგორ ვმუშაობთ
ინტეგრაციები ზუსტად შეერთების წერტილებში იშლება: პარტნიორის სერვისი ითიშება, Webhook ორჯერ მოდის, ველი იცვლება გაფრთხილების გარეშე. ჩვენ თავიდანვე ამ რისკების გათვალისწინებით ვაპროექტებთ: იდემპოტენტური დამმუშავებლებით, მოთხოვნების განმეორებით, dead letter რიგებითა და დეტალური ლოგირებით, რომელიც აჩვენებს ზუსტად რა გაიგზავნა და რა მივიღეთ. სპეციფიკაცია იწერება OpenAPI-ში ენდპოინტების შექმნამდე, რათა ორივე მხარემ პარალელურად შეძლოს მუშაობა.
ტექნოლოგიური დასტა
Laravel და Node.js სერვისები, OpenAPI კონტრაქტებისთვის, REST და Webhook-ები HTTP-ით, RabbitMQ და Redis რიგები ასინქრონული სამუშაოებისთვის, OAuth 2.0 სისტემებს შორის უსაფრთხო წვდომისთვის.
ხშირად დასმული კითხვები
მოჰყვება თუ არა API-ს დოკუმენტაცია?
დიახ. სპეციფიკაციას თავიდანვე ვწერთ OpenAPI ფორმატში და ვინახავთ რეპოზიტორიაში კოდის გვერდით, ამიტომ დოკუმენტაცია და ენდპოინტები ერთსა და იმავე commit-ში ახლდება. თქვენი გუნდი იღებს მოხერხებულ საინფორმაციო ბაზას მოთხოვნების ნიმუშებით და არა თვეების შემდეგ დაწერილ ბუნდოვან ტექსტს.
რა ხდება მაშინ, როდესაც პარტნიორი სერვისი შეფერხებით მუშაობს?
ჩვენ თავიდანვე ვუშვებთ, რომ ასეთი შემთხვევები გარდაუვალია. გამავალ მოთხოვნებს აქვს ლიმიტები (timeouts), განმეორების ლოგიკა ინტერვალების ზრდით (retries with backoff) და რიგები, რათა ნელმა პარტნიორმა არასდროს შეაფერხოს თქვენი მომხმარებელი. თუ სერვისი გათიშულია, დავალება ინახება dead letter queue-ში და განახლდება აღდგენისთანავე, დაკარგვის ნაცვლად.
როგორ მართავთ API-ის ვერსიებს?
დამატებითი ცვლილებები (additive changes) ემატება ახალი ვერსიის გარეშე. ძირეული ცვლილებები (breaking changes) იღებს ახალ ვერსიას, მიგრაციის გზამკვლევს და ძველი ვერსიის შენარჩუნების ვადას, რომელიც შეთანხმებულია ყველა მხარესთან და ხელმისაწვდომი რჩება მიგრაციის დასრულებამდე.
გაქვთ პროექტი? მოგვწერეთ: hello@longisoft.com