Παρακολούθηση API

Γιατί το API χρειάζεται δική του παρακολούθηση

Το API δεν είναι απλώς μια σελίδα στο /api/. Είναι ένα συμβόλαιο. Η μέθοδος HTTP έχει σημασία - το GET σε σχέση με το POST αλλάζει τη σημασιολογία. Τα headers μεταφέρουν ταυτοποίηση, διαπραγμάτευση περιεχομένου, idempotency keys. Το σώμα του αιτήματος είναι η είσοδος. Ο κωδικός απόκρισης έχει σημασία (401 σε σχέση με 403 σε σχέση με 422 - καθένας λέει διαφορετική ιστορία). Το σώμα της απόκρισης έχει δομή - JSON διαδρομές στις οποίες βασίζονται οι integrators. Ένα απλό uptime check που απλώς χτυπά το URL με GET θα χάσει τους περισσότερους τρόπους με τους οποίους το API μπορεί να καταρρεύσει: μη έγκυρο JSON που εξακολουθεί να επιστρέφει 200, endpoint ταυτοποίησης που δέχεται λανθασμένα δεδομένα, webhook με χαλασμένο σχήμα payload, endpoint που επιστρέφει 200 αλλά έχει μέσα "status": "error".

Η παρακολούθηση API το λύνει αυτό, δίνοντάς σου έλεγχο πάνω σε κάθε μέρος του αιτήματος και κάθε μέρος της επαλήθευσης της απόκρισης. Διαμορφώνεις ακριβώς την ίδια κλήση που κάνουν οι integrators σου - ίδια μέθοδος, ίδια headers, ίδιο body, ίδιο auth - και ακριβώς τι θεωρείται επιτυχία - ακριβείς κωδικοί, τιμές σε JSON paths, όρια χρόνου απόκρισης, μέγιστο μέγεθος.

Ρυθμίσεις αιτήματος

Για κάθε monitor API στο DiagnoSEO Uptime Monitoring μπορείς να ρυθμίσεις:

• Μέθοδος HTTP: GET, POST, PUT, PATCH, DELETE, HEAD. Επίλεξε αυτή που χρησιμοποιούν οι integrators σου.
• Custom headers: ως αντικείμενο JSON, π.χ. {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. Πρότυπο για έλεγχο OAuth, JWT, API keys, διαπραγμάτευση περιεχομένου.
• Σώμα αιτήματος: οποιοδήποτε string - JSON, XML, form-encoded, απλό κείμενο. Αποστέλλεται με POST/PUT/PATCH/DELETE.
• Basic auth: όνομα χρήστη και κωδικός, εάν το endpoint προστατεύεται έτσι.
• Αναμενόμενοι κωδικοί κατάστασης: λίστα ή εύρος. Από προεπιλογή 200-399, αλλά μπορείς να το περιορίσεις σε έναν κωδικό (π.χ. ακριβώς 201 για endpoint δημιουργίας) ή να επιτρέψεις συγκεκριμένους (π.χ. 200,202,204).

Ο έλεγχος ακολουθεί έως 5 ανακατευθύνσεις, αποκωδικοποιεί gzip, αναλύει το Content-Type για να ανιχνεύσει JSON. Κάθε έλεγχος αποθηκεύει τον πραγματικό κωδικό, χρόνο απόκρισης, μέγεθος και πιθανό σφάλμα. Πολλαπλές συνεχόμενες αποτυχίες (ρυθμιζόμενο, προεπιλεγμένα 2) προκαλούν συμβάν.

JSON path assertions

Οι ίδιοι οι status codes δεν αρκούν για πολλά API. Ένα health endpoint μπορεί να επιστρέψει 200 με body {"status": "degraded", "db": "down"} - ακόμη 200, αλλά σίγουρα πρέπει να το ξέρεις αυτό. Ένα API τιμών μπορεί να δώσει 200 με body όπου το data.price πεφτει σε null. Ένα API αναζήτησης μπορεί να επιστρέψει 200 με results: [], γιατί το index έπεσε.

Για τέτοιες περιπτώσεις διαμόρφωσε assertion JSON path. Βάλε τη διαδρομή (π.χ. data.status ή health.checks.db) και την αναμενόμενη τιμή (π.χ. healthy, true ή συγκεκριμένο αριθμό). Σε κάθε έλεγχο η απάντηση αποκοδικοποιείται από JSON και η τιμή στη διαδρομή συγκρίνεται. Μη αντιστοιχία καταλήγει το check ως αποτυχία, ανεξάρτητα από το HTTP status.

Η σύνταξη διαδρομής είναι dot notation με αγκύλες: data.items[0].id λειτουργεί, επίσης users.john.email. Η τιμή assertion συγκρίνεται ως string, οπότε το "true" ταιριάζει με bool true, και οι αριθμοί ταιριάζουν τόσο ως string όσο και ως αριθμοί.

Πρότυπα ταυτοποίησης

Τα δύο πιο συχνά στυλ auth λειτουργούν εξ αρχής. Για Bearer tokens (OAuth, JWT, API keys) χρησιμοποίησε το πεδίο headers: {"Authorization": "Bearer eyJhbGciOi..."}. Το token αποθηκεύεται στη διαμόρφωση του monitor και στέλνεται σε κάθε έλεγχο. Για basic auth χρησιμοποίησε τα ειδικά πεδία όνομα χρήστη/κωδικός - αποθηκεύονται και συνενώνονται στο κλασικό header.

Αν το auth απαιτεί signature ανά αίτημα ή ανανέωση token, είναι πιο δύσκολο. Δύο λογικά πρότυπα: (1) Ρύθμισε ένα long-lived service account token ειδικά για monitoring, ή (2) εξέθεσε ένα μη προστατευμένο health endpoint που αντανακλά το πραγματικό προστατευμένο και παρακολούθησέ το. Τα περισσότερα σύγχρονα API το προσφέρουν αυτό by default.

Προτεινόμενα πρότυπα

• Ένα monitor για κάθε κρίσιμο endpoint. Μην τεστάρεις κάθε endpoint - επίλεξε 5-10 που η αποτυχία τους θα είχε πραγματική ζημιά.
• Χρησιμοποίησε ακριβείς κωδικούς. Το default 200-399 είναι πολύ χαλαρό για API. Το endpoint δημιουργίας πρέπει να επιστρέφει ακριβώς 201· το idempotent ακριβώς 200· το login endpoint ακριβώς 200 (επιτυχία) ή 401 (καλοδιατυπωμένη αποτυχία - όχι 500).
• Συνδύασε status και JSON assertion. Μαζί εντοπίζουν προβλήματα μεταφοράς και περιεχομένου. Μόνο το status δεν εντοπίζει content errors· μόνο το JSON assertion είναι εύθραυστο στους redirect.
• Βάλε όριο χρόνου απόκρισης. Η υποβάθμιση API είναι πρώιμος δείκτης για προβλήματα dependencies. Monitor με rt_threshold_ms = 800 σου λέει ότι το API αργεί πριν πέσει εντελώς.
• Κράτα το body μικρό. Ο έλεγχος γίνεται κάθε λεπτό - μεγάλα bodies σπαταλούν εύρος ζώνης και από τις δύο πλευρές. Αρκούν ελάχιστα-αλλά-αντιπροσωπευτικά payloads.

Συνδυασμός με άλλους τύπους monitor

Για κάθε endpoint API το API monitor επαληθεύει ότι το call λειτουργεί. Ξεχωριστό ping ή port monitor ελέγχει αν ο host είναι ζωντανός. Ο SSL/domain έλεγχος στο ίδιο hostname πιάνει ζητήματα με το πιστοποιητικό και την καταχώριση. Το sub-monitor DNS προσέχει αλλαγές σε records που θα μπορούσαν να δείξουν κατάχρηση. Μαζί, τέσσερα monitor για ένα API δίνουν πλήρη εικόνα με ελάχιστη επικάλυψη.

Ρύθμιση

Άνοιξε το εργαλείο, πάτησε "Προσθήκη monitor", επίλεξε τύπο "API". Επικόλλησε το URL. Άνοιξε την ενότητα Για προχωρημένους. Επίλεξε μέθοδο, επικόλλησε headers ως JSON, επικόλλησε body αν χρειάζεται, βάλε basic auth αν το χρησιμοποιείς, γράψε τους αναμενόμενους κωδικούς (π.χ. 200 ή 200,201). Πρόσθεσε assertion JSON path αν είναι απαραίτητο. Ρύθμισε το διάστημα και το όριο επιβεβαίωσης. Αποθήκευσε. Από τον επόμενο κύκλο, το monitor καλεί το API σου ακριβώς όπως θα το έκανε ένας integrator, κάνει επαλήθευση της απόκρισης και ειδοποιεί αμέσως αν υπάρξει υποβάθμιση.

Συχνές ερωτήσεις

• Ποιες HTTP μεθόδους μπορώ να χρησιμοποιήσω για παρακολούθηση API;

  GET, POST, PUT, DELETE, PATCH και HEAD. Ρυθμίζεις μέθοδο ανά monitor — για write endpoints (POST/PUT/PATCH) το body request προσαρμόζεται επίσης ως JSON string ή form data.

• Πώς λειτουργούν τα JSON assertions;

  Δίνεις το JSON path (π.χ. data.status ή results[0].id) και την αναμενόμενη τιμή. Το monitor λαμβάνει την απόκριση, την αναλύει ως JSON, εξάγει το path και συγκρίνει με το αναμενόμενο. Αν δεν ταιριάζουν, το check αποτυγχάνει με λάθος "assertion failed" που δείχνει την πραγματική τιμή.

• Μπορώ να στέλνω headers ταυτοποίησης;

  Ναι. Τα custom HTTP headers ρυθμίζονται ανά monitor — tokens Authorization, API keys, content-type, οτιδήποτε. Οι τιμές των headers κρυπτογραφούνται στην βάση όσο αποθηκεύονται. Για Basic Auth υπάρχει ειδικό πεδίο username/password που αυτόματα υπογράφει το αίτημα.

• Τι αν το API μου επιστρέφει 200 με body λάθους;

  Συνηθισμένο pattern: Το API επιστρέφει HTTP 200 αλλά το body λέει {"status":"error"}. Ένα απλό uptime monitor νομίζει ότι είναι υγιές. Χρησιμοποίησε JSON assertion status == "ok" για να το πιάσεις — το assertion αποτυγχάνει και το monitor αναφέρει ΚΑΤΩ ακόμη κι αν το HTTP είναι 200.

• Πώς να χειριστώ API με rate limit;

  Ρύθμισε τη συχνότητα ελέγχου ώστε να τηρείς το όριο API (π.χ. ανά 5 λεπτά αν το API επιτρέπει 12 κλήσεις/ώρα). Το monitor μετρά ως μία API κλήση ανά check από κάθε περιοχή. Τα multi-region checks πολλαπλασιάζουν τις κλήσεις — επίλεξε single-region αν το API σου έχει αυστηρά όρια.