Τεκμηρίωση του UPS Tracking API: 7 βασικές δυνατότητες που πρέπει να γνωρίζουν οι προγραμματιστές

Η τεκμηρίωση του UPS tracking API είναι πιο χρήσιμη όταν βοηθά έναν προγραμματιστή να μεταβεί από έναν αριθμό παρακολούθησης σε μια αξιόπιστη εμπειρία ενημέρωσης κατάστασης αποστολής. Οι επτά τομείς που πρέπει να εξεταστούν είναι ο έλεγχος ταυτότητας, τα αιτήματα παρακολούθησης, τα σχήματα αποκρίσεων, το ιστορικό συμβάντων, η διαχείριση σφαλμάτων, τα λειτουργικά όρια και οι δοκιμές. Η UPS παρέχει τη δική της πλατφόρμα προγραμματιστών για άμεσες ενσωματώσεις UPS, ενώ μια υπηρεσία πολλαπλών μεταφορέων, όπως το 17TRACK Tracking API, μπορεί να είναι καταλληλότερη όταν μία ενσωμάτωση πρέπει να υποστηρίζει την UPS και άλλους μεταφορείς.

Η σωστή υλοποίηση εξαρτάται από το σύστημα που δημιουργείτε. Ένας λιανοπωλητής μπορεί να χρειάζεται ενημερώσεις παράδοσης στη σελίδα μιας παραγγελίας, μια ομάδα αποθήκης μπορεί να χρειάζεται ειδοποιήσεις για εξαιρέσεις και μια επιχειρησιακή πλατφόρμα μπορεί να χρειάζεται κανονικοποιημένα δεδομένα παρακολούθησης από πολλούς μεταφορείς. Η ανάγνωση της τεκμηρίωσης μέσα από αυτά τα σενάρια χρήσης βοηθά στην αποφυγή ενός συνηθισμένου λάθους: να θεωρείται ότι μια επιτυχής απόκριση API είναι το ίδιο με μια ολοκληρωμένη λύση ορατότητας αποστολών.

Τι θα πρέπει να σας βοηθά να απαντήσετε η τεκμηρίωση του UPS tracking API

Πριν γράψετε κώδικα, διευκρινίστε τέσσερις ερωτήσεις:

• Ενσωματώνετε μόνο την UPS ή το σύστημα θα παρακολουθεί πολλούς μεταφορείς;
• Χρειάζεστε την τρέχουσα κατάσταση του πακέτου, το πλήρες ιστορικό σαρώσεων ή και τα δύο;
• Η εφαρμογή σας θα ζητά ενημερώσεις κατ’ απαίτηση, θα λαμβάνει ειδοποιήσεις ή θα χρησιμοποιεί συνδυασμό;
• Τι θα πρέπει να βλέπουν οι πελάτες και οι εσωτερικές ομάδες όταν μια αποστολή καθυστερεί, παραδόθηκε, επιστράφηκε ή δεν έχει βρεθεί ακόμη;

Η τεκμηρίωση της UPS είναι η κύρια πηγή για τα τρέχοντα διαπιστευτήρια, τις υποστηριζόμενες λειτουργίες, τις απαιτήσεις αιτημάτων, τα πεδία αποκρίσεων και τις προϋποθέσεις εμπορικής πρόσβασης. Αυτές οι λεπτομέρειες μπορεί να αλλάζουν ανάλογα με το προϊόν API, τη ρύθμιση του λογαριασμού ή την έκδοση της πλατφόρμας προγραμματιστών, επομένως ο κώδικας παραγωγής θα πρέπει να ακολουθεί την τρέχουσα πύλη προγραμματιστών της UPS και όχι ένα παλιό δείγμα κώδικα.

7 βασικές δυνατότητες που πρέπει να κατανοούν οι προγραμματιστές

1. Έλεγχος ταυτότητας και πρόσβαση εφαρμογής

Ο έλεγχος ταυτότητας είναι η πρώτη πρακτική δυνατότητα, επειδή καθορίζει τον τρόπο με τον οποίο μια εφαρμογή αποδεικνύει την ταυτότητά της και αποκτά άδεια να καλεί το API. Η τεκμηρίωση προγραμματιστών της UPS παρέχει την τρέχουσα διαδικασία για την εγγραφή μιας εφαρμογής, τη δημιουργία διαπιστευτηρίων, το αίτημα πρόσβασης και τη διαχείριση διακριτικών. Η τεκμηρίωση περιγράφει πρόσβαση βάσει OAuth για τα UPS APIs, αλλά οι προγραμματιστές θα πρέπει να επιβεβαιώνουν τη σημερινή ροή παραχώρησης, τα scopes, τη διάρκεια ζωής των διακριτικών και τις απαιτήσεις περιβάλλοντος στην ενεργή πύλη πριν από την υλοποίηση.

Διατηρείτε τα διαπιστευτήρια στην πλευρά του διακομιστή. Δεν θα πρέπει να ενσωματώνονται σε JavaScript του browser, σε εκδόσεις για κινητά, σε δημόσια αποθετήρια ή σε κώδικα σελίδων παρακολούθησης που είναι ορατός στον πελάτη. Μια ασφαλέστερη αρχιτεκτονική τοποθετεί μια υπηρεσία backend ανάμεσα στην εφαρμογή που βλέπει ο πελάτης και την UPS. Η υπηρεσία αυτή μπορεί να πραγματοποιεί ασφαλή έλεγχο ταυτότητας, να επιβάλλει όρια αιτημάτων, να καταγράφει τεχνικά αποτελέσματα χωρίς να εκθέτει μυστικά και να επιστρέφει μόνο τα δεδομένα αποστολής που χρειάζεται το frontend.

Διαχωρίστε επίσης τα διαπιστευτήρια ανάπτυξης από τα διαπιστευτήρια παραγωγής, όπου η πλατφόρμα της UPS υποστηρίζει ξεχωριστά περιβάλλοντα. Μια λίστα ελέγχου ανάπτυξης θα πρέπει να περιλαμβάνει την αποθήκευση μυστικών, την περιστροφή τους, την ιδιοκτησία πρόσβασης, τη διαχείριση ληγμένων διακριτικών και μια ειδοποίηση όταν οι αποτυχίες ελέγχου ταυτότητας αρχίζουν να αυξάνονται.

2. Αιτήματα αριθμών παρακολούθησης και πλαίσιο μεταφορέα

Μια ενσωμάτωση παρακολούθησης χρειάζεται έναν προβλέψιμο τρόπο υποβολής ενός αναγνωριστικού παρακολούθησης και αιτήματος πληροφοριών αποστολής. Τα σημαντικά ερωτήματα δεν αφορούν μόνο τη διεύθυνση του endpoint. Περιλαμβάνουν τη μορφή αριθμού παρακολούθησης που γίνεται αποδεκτή, το αν το αίτημα υποστηρίζει έναν ή πολλούς αριθμούς, τον τρόπο αναγνώρισης του μεταφορέα και τον τρόπο απόκρισης του API όταν ο αριθμός είναι ελλιπής ή δεν έχει αναγνωριστεί ακόμη.

Μην υποθέτετε ότι κάθε συμβολοσειρά που μοιάζει με αριθμό παρακολούθησης ανήκει στην UPS. Αν η εφαρμογή σας λαμβάνει ετικέτες από διάφορα συστήματα αποστολής, αποθηκεύετε τον μεταφορέα ως ξεχωριστό πεδίο όποτε είναι γνωστός. Η δρομολόγηση με επίγνωση του μεταφορέα μειώνει τις εσφαλμένες αντιστοιχίσεις και διευκολύνει την αντιμετώπιση προβλημάτων. Δημιουργεί επίσης μια καθαρή πορεία για μελλοντική επέκταση, αν η επιχείρησή σας προσθέσει άλλον μεταφορέα.

Επικυρώνετε την είσοδο πριν από την υποβολή αιτήματος, αλλά αποφεύγετε την υπερβολικά αυστηρή επικύρωση που απορρίπτει ένα έγκυρο αναγνωριστικό επειδή άλλαξε η μορφή του ή επειδή η ετικέτα δημιουργήθηκε πρόσφατα. Η απόκριση του API παραμένει ο οριστικός έλεγχος. Αποθηκεύετε την αρχική τιμή, μια κανονικοποιημένη τιμή που χρησιμοποιείται για αναζήτηση, τον μεταφορέα, την αναφορά παραγγελίας και την ώρα του τελευταίου επιτυχούς ερωτήματος.

3. Ένα δομημένο σχήμα απόκρισης

Η χρήσιμη τεκμηρίωση του UPS tracking API εξηγεί πώς οργανώνονται τα δεδομένα αποστολής και ποια πεδία είναι προαιρετικά. Οι προγραμματιστές θα πρέπει να εξετάζουν το μοντέλο απόκρισης για την ταυτότητα της αποστολής, την τρέχουσα κατάσταση, την περιγραφή κατάστασης, τις χρονικές σημάνσεις σαρώσεων, τις τοποθεσίες, τις εκτιμήσεις παράδοσης, τις πληροφορίες υπηρεσίας και τις λεπτομέρειες σε επίπεδο πακέτου. Ένα πεδίο που απουσιάζει δεν είναι απαραίτητα ίδιο με ένα πεδίο που περιέχει κενή τιμή και κανένα από τα δύο δεν θα πρέπει να αντιμετωπίζεται αυτόματα ως αποτυχημένη αποστολή.

Δημιουργήστε ένα κανονικοποιημένο εσωτερικό μοντέλο αντί να συνδέετε ολόκληρη την εφαρμογή απευθείας με ονόματα πεδίων συγκεκριμένου παρόχου. Για παράδειγμα, η βάση δεδομένων σας μπορεί να διατηρεί ένα αναγνωριστικό αποστολής, τον μεταφορέα, την τρέχουσα κατάσταση, την ώρα του τελευταίου συμβάντος, την εκτιμώμενη ώρα παράδοσης, την ώρα παράδοσης, τον κωδικό εξαίρεσης και το ακατέργαστο payload του παρόχου. Τα κανονικοποιημένα πεδία υποστηρίζουν αναφορές και διεπαφές χρήστη· το ακατέργαστο payload υποστηρίζει ελέγχους και μελλοντικές αλλαγές αντιστοίχισης.

Διατηρείτε τις χρονικές σημάνσεις μαζί με την απόκλιση ή τις πληροφορίες ζώνης ώρας, όταν παρέχονται. Η εμφάνιση μιας σάρωσης από μία τοποθεσία σαν να συνέβη στην τοπική ώρα του θεατή μπορεί να δημιουργήσει συγκεχυμένες αφηγήσεις παράδοσης. Ομοίως, μην μετατρέπετε τη λεπτομερή κατάσταση ενός μεταφορέα σε απλούστερη ετικέτα προτού τεκμηριωθεί ο επιχειρηματικός κανόνας.

4. Ιστορικό σαρώσεων και ερμηνεία κατάστασης

Η αξία του UPS tracking βρίσκεται συχνά στη σειρά των συμβάντων και όχι σε μία μόνο τρέχουσα ετικέτα. Ένα πακέτο μπορεί να περάσει από τη δημιουργία ετικέτας, την παραλαβή, τη μεταφορά, μια σάρωση άφιξης, μια εξαίρεση, ένα συμβάν «προς παράδοση» και την παράδοση. Μια χρήσιμη ενσωμάτωση αποθηκεύει τα συμβάντα με τη σειρά και διατηρεί, όπου είναι δυνατόν, τις αρχικές περιγραφές τους.

Η αντιστοίχιση καταστάσεων απαιτεί συντακτική και επιχειρησιακή κρίση. Η ένδειξη «σε μεταφορά» μπορεί να καλύπτει αρκετά διαφορετικά στάδια, ενώ η ένδειξη «εξαίρεση» μπορεί να απαιτεί εξήγηση πιο συγκεκριμένη από το όνομα της κατάστασης. Η εφαρμογή σας θα πρέπει να διακρίνει τουλάχιστον μεταξύ κανονικής μετακίνησης, δραστηριότητας παράδοσης, παραδομένου, εξαίρεσης, επιστροφής και κατάστασης που δεν μπορεί ακόμη να προσδιοριστεί. Η ακριβής αντιστοίχιση πρέπει να ακολουθεί τα πεδία και τους κωδικούς που τεκμηριώνει η UPS και όχι υποθέσεις βασισμένες μόνο σε αγγλικές περιγραφές.

Για σελίδες που απευθύνονται σε πελάτες, εμφανίζετε το πιο πρόσφατο ουσιαστικό συμβάν, την ώρα του και μια σύντομη εξήγηση. Για τις εσωτερικές λειτουργίες, διατηρείτε το πλήρες ιστορικό συμβάντων και την αρχική διατύπωση του μεταφορέα. Αυτό επιτρέπει στο προσωπικό υποστήριξης να διερευνά ένα παράπονο χωρίς να ζητά από τον πελάτη να επαναλάβει πληροφορίες που έχει ήδη λάβει το σύστημα.

5. Εκτιμήσεις παράδοσης και διαχείριση εξαιρέσεων

Οι προγραμματιστές συχνά επικεντρώνονται στην κανονική ροή, όμως οι εκτιμήσεις παράδοσης και οι εξαιρέσεις καθορίζουν αν τα δεδομένα παρακολούθησης είναι πρακτικά χρήσιμα. Μια αποστολή μπορεί να μην έχει εκτίμηση, μια εκτίμηση μπορεί να αλλάξει ή μια εξαίρεση μπορεί να διακόψει προσωρινά την κανονική μετακίνηση. Η τεκμηρίωση θα πρέπει να ελέγχεται για τα πεδία και τις συνθήκες που αναπαριστούν αυτές τις περιπτώσεις.

Ποτέ μην παρουσιάζετε μια εκτίμηση ως εγγύηση, εκτός αν οι σχετικοί όροι υπηρεσίας της UPS υποστηρίζουν ρητά αυτή την ερμηνεία. Στη διεπαφή χρήστη, επισημαίνετε μια εκτίμηση ως εκτίμηση και εμφανίζετε την ημερομηνία ή το χρονικό παράθυρο ακριβώς όπως υποστηρίζεται από τα δεδομένα. Αν το API παραλείπει μια εκτίμηση, εμφανίζετε ένα ουδέτερο μήνυμα όπως «Δεν υπάρχει διαθέσιμη εκτίμηση παράδοσης αυτήν τη στιγμή» αντί να επινοείτε μία από έναν γενικό κανόνα χρόνου μεταφοράς.

Οι ροές εργασίας εξαιρέσεων θα πρέπει να είναι ρητές. Αποφασίστε αν μια νέα εξαίρεση ενεργοποιεί email, εργασία στο help desk, ενέργεια διαχείρισης παραγγελίας ή μόνο αλλαγή κατάστασης. Προσθέστε αποδιπλοποίηση, ώστε η επαναλαμβανόμενη δημοσκόπηση να μην αποστέλλει την ίδια ειδοποίηση πολλές φορές. Ένας πρακτικός κανόνας είναι η σύγκριση του αναγνωριστικού συμβάντος ή ενός σταθερού συνδυασμού ώρας συμβάντος, κατάστασης και περιγραφής πριν από τη δημιουργία νέας ειδοποίησης.

6. Σφάλματα, επαναλήψεις και λειτουργικά όρια

Η τεκμηρίωση API θα πρέπει να διαβάζεται ως λειτουργική σύμβαση και όχι μόνο ως κατάλογος επιτυχημένων παραδειγμάτων. Οι προγραμματιστές πρέπει να κατανοούν τα σφάλματα ελέγχου ταυτότητας, τα μη έγκυρα αιτήματα, τους άγνωστους αριθμούς παρακολούθησης, τις προσωρινές διακοπές υπηρεσίας, τα χρονικά όρια και τις αποκρίσεις ορίων ρυθμού. Κάθε κατηγορία απαιτεί διαφορετική απόκριση.

• Οι αποτυχίες ελέγχου ταυτότητας θα πρέπει να δημιουργούν ειδοποίηση για την ομάδα μηχανικής και δεν θα πρέπει να επαναλαμβάνονται επ’ αόριστον.
• Τα σφάλματα επικύρωσης θα πρέπει να καταγράφονται με αρκετό πλαίσιο ώστε να διορθωθεί το αίτημα.
• Οι προσωρινές αποτυχίες μπορούν να επαναλαμβάνονται με εκθετική καθυστέρηση και μέγιστο αριθμό προσπαθειών.
• Οι άγνωστοι ή πρόσφατα δημιουργημένοι αριθμοί παρακολούθησης μπορούν να ελέγχονται ξανά αργότερα, αλλά δεν θα πρέπει να χαρακτηρίζονται ως χαμένοι.
• Οι αποκρίσεις ορίου ρυθμού θα πρέπει να επιβραδύνουν το πρόγραμμα δημοσκόπησης και να σέβονται τα όρια που αναφέρονται στην τρέχουσα τεκμηρίωση της UPS.

Χρησιμοποιείτε χρονικά όρια, διακόπτες κυκλώματος, αναγνωριστικά αιτημάτων και δομημένα αρχεία καταγραφής. Αποθηκεύετε την κατάσταση απόκρισης του παρόχου, το εσωτερικό αναγνωριστικό αποστολής και τη χρονική σήμανση, εξαιρώντας τα διακριτικά πρόσβασης και τις περιττές προσωπικές πληροφορίες. Αν η τεκμηρίωση καθορίζει κεφαλίδες απόκρισης ή οδηγίες επανάληψης, ενσωματώστε αυτές τις οδηγίες αντί να εφαρμόσετε μια γενική πολιτική.

7. Δοκιμές, παρακολούθηση και ετοιμότητα παραγωγής

Μια ενσωμάτωση tracking API θα πρέπει να δοκιμάζεται με περισσότερους από έναν επιτυχημένους αριθμούς παρακολούθησης. Δημιουργήστε περιπτώσεις δοκιμών για μια νεοδημιουργημένη ετικέτα, μια αποστολή με πολλές σαρώσεις, μια εξαίρεση, ένα παραδομένο πακέτο, έναν άγνωστο αριθμό, ένα ληγμένο διαπιστευτήριο, ένα εσφαλμένα διαμορφωμένο αίτημα, ένα χρονικό όριο και ένα διπλότυπο συμβάν. Τα ακριβή δεδομένα δοκιμών και η συμπεριφορά του sandbox πρέπει να επιβεβαιώνονται στο περιβάλλον προγραμματιστών της UPS, επειδή τα δεδομένα πραγματικών αποστολών και τα περιβάλλοντα δοκιμών δεν συμπεριφέρονται πάντα με τον ίδιο τρόπο.

Παρακολουθείτε τόσο τα τεχνικά όσο και τα επιχειρηματικά αποτελέσματα. Οι τεχνικές μετρήσεις περιλαμβάνουν τον όγκο αιτημάτων, την καθυστέρηση, το ποσοστό χρονικών ορίων, τις αποτυχίες ελέγχου ταυτότητας, το ποσοστό σφαλμάτων παρόχου και τον αριθμό επαναλήψεων. Οι επιχειρηματικές μετρήσεις περιλαμβάνουν το ποσοστό αποστολών με πρόσφατο συμβάν, την ηλικία της παλαιότερης αποστολής που δεν έχει ανανεωθεί και τον αριθμό παραγγελιών που επηρεάζονται από μια εξαίρεση. Μια υπηρεσία μπορεί να έχει χαμηλό ποσοστό σφαλμάτων HTTP και παρ’ όλα αυτά να παρέχει παρωχημένες πληροφορίες παρακολούθησης, αν έχει σταματήσει η δημοσκόπηση ή η επεξεργασία συμβάντων.

Πριν από την έναρξη, τεκμηριώστε τον τρόπο παύσης της δημοσκόπησης, περιστροφής των διαπιστευτηρίων, επανάληψης αποτυχημένων αποκρίσεων, διόρθωσης μιας εσφαλμένης αντιστοίχισης κατάστασης και επικοινωνίας με την υποστήριξη της UPS. Διατηρείτε το payload του παρόχου για ελεγχόμενη περίοδο διατήρησης, αν χρειάζεται για διερεύνηση, και εξετάζετε τις απαιτήσεις απορρήτου και διατήρησης δεδομένων με τον κατάλληλο υπεύθυνο.

Άμεση ενσωμάτωση UPS ή API πολλαπλών μεταφορέων;

Μια άμεση ενσωμάτωση UPS είναι λογική επιλογή όταν η UPS είναι ο μόνος μεταφορέας στο πεδίο εφαρμογής, η ομάδα θέλει να διαχειρίζεται το μοντέλο που αφορά τον μεταφορέα και είναι διαθέσιμη η απαιτούμενη πρόσβαση στο UPS API. Μπορεί να προσφέρει στενή αντιστοίχιση με την ορολογία και τις λειτουργικές διαδικασίες της UPS.

Ένα API πολλαπλών μεταφορέων μπορεί να ταιριάζει καλύτερα αρχιτεκτονικά όταν η ίδια εφαρμογή πρέπει να παρακολουθεί δέματα από την UPS, ταχυδρομικούς φορείς και άλλους παρόχους logistics. Η τεκμηρίωση του 17TRACK API θα πρέπει να εξεταστεί ως προς το τρέχον μοντέλο ελέγχου ταυτότητας, τις υποστηριζόμενες λειτουργίες, τη δομή αποκρίσεων, τη συμπεριφορά webhook, τους όρους χρήσης και την κάλυψη μεταφορέων πριν ληφθεί τεχνική απόφαση. Η αξία του σε αυτό το σενάριο δεν είναι ότι καταργεί την ανάγκη για τεκμηρίωση· είναι ότι η ομάδα ανάπτυξης μπορεί να αξιολογήσει ένα επίπεδο ενσωμάτωσης έναντι του κόστους συντήρησης πολλών συνδέσεων ειδικά για κάθε μεταφορέα.

Κάντε τη σύγκριση με μια απόδειξη ιδέας. Χρησιμοποιήστε τον ίδιο κύκλο ζωής αποστολής για κάθε επιλογή και μετρήστε την προσπάθεια υλοποίησης, την πληρότητα πεδίων, την επικαιρότητα συμβάντων, τη συμπεριφορά επαναλήψεων, τις απαιτήσεις webhook ή δημοσκόπησης, την παρατηρησιμότητα και την εργασία που απαιτείται όταν ένας μεταφορέας αλλάζει την απόκρισή του. Μην επιλέγετε έναν πάροχο μόνο επειδή ένα δείγμα αιτήματος είναι σύντομο. Η καλύτερη επιλογή είναι αυτή που υποστηρίζει το λειτουργικό αποτέλεσμα που πρέπει να παρέχει η εφαρμογή σας.

Μια πρακτική σειρά υλοποίησης

1. Καθορίστε τα αποτελέσματα για τον χρήστη και τις λειτουργίες, όπως μια σελίδα παρακολούθησης πελάτη ή μια ουρά εξαιρέσεων.
2. Επιβεβαιώστε αν το πεδίο εφαρμογής αφορά μόνο την UPS ή πολλούς μεταφορείς.
3. Διαβάστε την τρέχουσα επίσημη τεκμηρίωση για τον έλεγχο ταυτότητας, τα αιτήματα παρακολούθησης, τα πεδία αποκρίσεων, τα σφάλματα, τα όρια και τις δοκιμές.
4. Δημιουργήστε ένα μοντέλο αποστολής και συμβάντων ανεξάρτητο από τον πάροχο.
5. Υλοποιήστε ασφαλή έλεγχο ταυτότητας στην πλευρά του διακομιστή και επικύρωση εισόδου.
6. Αποθηκεύστε ξεχωριστά τις ακατέργαστες αποκρίσεις και τα κανονικοποιημένα πεδία.
7. Προσθέστε δημοσκόπηση ή λήψη συμβάντων με αποδιπλοποίηση και εκθετική καθυστέρηση.
8. Δοκιμάστε κανονικά, καθυστερημένα, εξαιρετικά, άγνωστα και αποτυχημένα αιτήματα.
9. Ξεκινήστε με παρακολούθηση της επικαιρότητας, των αποτυχιών και των παρωχημένων αποστολών.

Αυτή η σειρά εμποδίζει το API call να γίνει ολόκληρος ο σχεδιασμός. Η παρακολούθηση είναι μια συνεχής διαδικασία δεδομένων: η εφαρμογή πρέπει να λαμβάνει συμβάντα, να τα ερμηνεύει προσεκτικά, να τα παρουσιάζει καθαρά και να ανακάμπτει όταν ο πάροχος ή το δίκτυο δεν είναι διαθέσιμο.

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

Τι θα πρέπει να διαβάσω πρώτο στην τεκμηρίωση του UPS tracking API;

Ξεκινήστε με τον έλεγχο ταυτότητας και τη λειτουργία παρακολούθησης. Στη συνέχεια εξετάστε τις απαιτήσεις αιτημάτων, τα πεδία αποκρίσεων, τη συμπεριφορά σφαλμάτων, τα όρια χρήσης και τις οδηγίες δοκιμών. Αυτές οι ενότητες αποκαλύπτουν αν το API ταιριάζει στο μοντέλο ασφαλείας και στις απαιτήσεις δεδομένων σας πριν επενδύσετε σε πλήρη ενσωμάτωση.

Μπορώ να χρησιμοποιήσω ένα UPS tracking API για σελίδα παρακολούθησης που απευθύνεται σε πελάτες;

Ναι, ένα API μπορεί να παρέχει δεδομένα για σελίδα που απευθύνεται σε πελάτες, αλλά η σελίδα θα πρέπει να εξυπηρετείται μέσω του backend σας αντί να εκθέτει τα διαπιστευτήρια API στον browser. Σχεδιάστε τη σελίδα ώστε να διακρίνει την τρέχουσα κατάσταση, το ιστορικό σαρώσεων, τις εκτιμήσεις και τις εξαιρέσεις και αποφύγετε την παρουσίαση εκτιμήσεων ως εγγυήσεων.

Πρέπει οι αριθμοί παρακολούθησης να ελέγχονται συνεχώς;

Όχι απαραίτητα. Η συχνότητα δημοσκόπησης θα πρέπει να αντανακλά το στάδιο της αποστολής, την επιχειρηματική επείγουσα ανάγκη, τα τεκμηριωμένα όρια χρήσης και το αν είναι διαθέσιμη μια επιλογή που βασίζεται σε συμβάντα. Χρησιμοποιήστε καθυστέρηση για αποστολές χωρίς αλλαγές και σταματήστε ή μειώστε τη δημοσκόπηση μετά την παράδοση ή μετά από τελική κατάσταση επιστροφής.

Ποια είναι η διαφορά μεταξύ άγνωστου αριθμού παρακολούθησης και χαμένου πακέτου;

Άγνωστος αριθμός παρακολούθησης σημαίνει ότι το τρέχον αίτημα δεν επέστρεψε αναγνωρισμένο αποτέλεσμα αποστολής. Μπορεί να δημιουργήθηκε πρόσφατα, να καταχωρίστηκε λανθασμένα, να δρομολογήθηκε σε λάθος μεταφορέα ή να μην είναι προσωρινά διαθέσιμος. Δεν θα πρέπει να χαρακτηρίζεται ως χαμένο χωρίς ξεχωριστή επιχειρηματική διαδικασία και υποστηρικτικά στοιχεία.

Πότε αξίζει να εξεταστεί ένα API παρακολούθησης πολλαπλών μεταφορέων;

Αξίζει να αξιολογηθεί όταν η εφαρμογή σας πρέπει να υποστηρίζει πολλούς μεταφορείς ή όταν η διατήρηση ξεχωριστού ελέγχου ταυτότητας, σχημάτων, αντιστοιχίσεων καταστάσεων και πολιτικών σφαλμάτων θα δημιουργούσε σημαντική λειτουργική εργασία. Συγκρίνετε τους παρόχους χρησιμοποιώντας πραγματικά σενάρια αποστολών και επαληθεύστε τις τρέχουσες πληροφορίες μεταφορέων και δυνατοτήτων στην επίσημη τεκμηρίωσή τους.

Πηγές

• UPS Developer Portal — επίσημο σημείο πρόσβασης για τα προϊόντα UPS API, τη ρύθμιση εφαρμογών, τον έλεγχο ταυτότητας και τους πόρους προγραμματιστών.
• UPS Tracking — επίσημη υπηρεσία παρακολούθησης της UPS και αναφορά ορολογίας.
• 17TRACK Tracking API — επίσημη σελίδα προϊόντος για την αξιολόγηση μιας ενσωμάτωσης παρακολούθησης πολλαπλών μεταφορέων.
• 17TRACK API Documentation — επίσημη τεκμηρίωση προγραμματιστών για τις τρέχουσες λεπτομέρειες API και τις απαιτήσεις ενσωμάτωσης.