Interceptor — τι είναι, τύποι παρεμβολέων OkHttp και Alamofire

Τι είναι το Interceptor;

Interceptor — στοιχείο λογισμικού που εισάγεται στον πελάτη HTTP για παρεμβολή και τροποποίηση αιτημάτων πριν από την αποστολή στον διακομιστή και αποκρίσεων πριν από τη μεταφορά στην εφαρμογή. Στην κινητή ανάπτυξη, οι παρεμβολείς λύνουν διατομεακές εργασίες: αυτόματη προσθήκη κουπονιών ελέγχου ταυτότητας, καταγραφή κίνησης με μέτρηση χρόνου, επαναλήψεις σε προσωρινά σφάλματα δικτύου, συμπίεση και αποκρυπτογράφηση δεδομένων εν κινήσει. Η αρχιτεκτονική Interceptor βασίζεται στο μοτίβο Chain of Responsibility — κάθε παρεμβολέας μπορεί να τροποποιήσει το αίτημα, να το εκτελέσει ή να διακόψει την αλυσίδα επιστρέφοντας μια προσαρμοσμένη απόκριση.

Πώς λειτουργεί η αλυσίδα παρεμβολέων

Στο OkHttp, οι παρεμβολείς σχηματίζουν μια αλυσίδα (chain). Κάθε Interceptor λαμβάνει ένα αντικείμενο Chain με το αρχικό αίτημα και καλεί το chain.proceed(request) για να μεταβιβάσει τον έλεγχο στον επόμενο παρεμβολέα. Μετά τη λήψη της απόκρισης, ο παρεμβολέας μπορεί να αναλύσει το Response, να το τροποποιήσει, να επαναλάβει το αίτημα σε σφάλμα ή να επιστρέψει μια προσαρμοσμένη απόκριση για προσωρινή αποθήκευση. Η σειρά προσθήκης παρεμβολέων στο OkHttpClient.Builder καθορίζει τη σειρά εκτέλεσής τους: ο πρώτος που προστίθεται εκτελείται πρώτος κατά την αποστολή και τελευταίος κατά τη λήψη.

Interceptor στο OkHttp: Application και Network

OkHttp χωρίζει τους παρεμβολείς σε δύο τύπους. Application Interceptor (addInterceptor) εκτελείται μεταξύ του κώδικα εφαρμογής και OkHttp: μία κλήση chain.proceed() — ένα αίτημα στον διακομιστή, ανεξάρτητα από ανακατευθύνσεις. Network Interceptor (addNetworkInterceptor) εκτελείται εντός OkHttp μετά τον σχηματισμό κεφαλίδων και σύνδεσης — ενεργοποιείται σε κάθε ανακατεύθυνση, επανάληψη ή έλεγχο ταυτότητας. Αυτή η διαφορά είναι κρίσιμη για τη σωστή επιλογή τύπου παρεμβολέα για μια συγκεκριμένη εργασία.

class LoggingInterceptor : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val request = chain.request()
        Log.d("HTTP", "${request.method} ${request.url}")

        val startTime = System.currentTimeMillis()
        val response = chain.proceed(request)
        val duration = System.currentTimeMillis() - startTime

        Log.d("HTTP", "${response.code} σε ${duration}ms")
        return response
    }
}

val client = OkHttpClient.Builder()
    .addInterceptor(LoggingInterceptor())
    .addNetworkInterceptor(CacheInterceptor())
    .build()

LoggingInterceptor — Application Interceptor που καταγράφει τη μέθοδο, URL, κωδικό απόκρισης και χρόνο εκτέλεσης. Η προσθήκη μέσω addInterceptor() εγγυάται ένα αρχείο καταγραφής ανά αίτημα χρήστη χωρίς διπλασιασμό σε ανακατευθύνσεις. CacheInterceptor προστέθηκε ως Network Interceptor για να λαμβάνει υπόψη τις κεφαλίδες Cache-Control του διακομιστή, οι οποίες είναι ορατές μόνο εντός OkHttp μετά τον σχηματισμό του αιτήματος HTTP.

Διαφορά μεταξύ τύπων στην πράξη

Όταν η εφαρμογή κάνει ένα αίτημα, ο διακομιστής μπορεί να απαντήσει με ανακατεύθυνση 302 ή 301. Application Interceptor θα δει μόνο την τελική απόκριση μετά από όλες τις ανακατευθύνσεις — δεν γνωρίζει πόσα ενδιάμεσα αιτήματα έγιναν. Network Interceptor θα δει κάθε αίτημα και απόκριση, συμπεριλαμβανομένων των ενδιάμεσων. Σύμφωνα με στοιχεία της Square (2026), το Network Interceptor βλέπει επίσης δεδομένα συμπιεσμένα σε επίπεδο σύνδεσης (gzip), ενώ το Application Interceptor λαμβάνει ήδη αποσυμπιεσμένη απόκριση. Για την καταμέτρηση του πραγματικού αριθμού κλήσεων δικτύου, χρησιμοποιήστε το Network Interceptor.

Alamofire RequestInterceptor

Alamofire παρέχει το πρωτόκολλο RequestInterceptor, που συνδυάζει δύο πρωτόκολλα: RequestAdapter για τροποποίηση του αιτήματος πριν από την αποστολή και RequestRetrier για επαναλήψεις σε σφάλματα. Αυτός ο διαχωρισμός επιτρέπει τον ευέλικτο συνδυασμό της προσαρμογής (προσθήκη κεφαλίδων, κουπονιών) με την πολιτική επαναλήψεων (εκθετική καθυστέρηση, όριο προσπαθειών, έλεγχος τύπου σφάλματος). Το RequestInterceptor υλοποιείται από μία δομή ή κλάση που υλοποιεί και τα δύο πρωτόκολλα.

struct AuthInterceptor: RequestInterceptor {
    private let tokenProvider: TokenProvider

    func adapt(_ urlRequest: URLRequest,
                using state: Session.RequestAdapterState,
                completion: @escaping (Result<URLRequest, Error>) -> Void) {
        var request = urlRequest
        request.setValue("Bearer \(tokenProvider.token)",
                        forHTTPHeaderField: "Authorization")
        completion(.success(request))
    }

    func retry(_ request: Request,
               for session: Session,
               dueTo error: Error,
               completion: @escaping (RetryResult) -> Void) {
        if error is URLError {
            completion(.retryWithDelay(1))
        } else {
            completion(.doNotRetry)
        }
    }
}

AuthInterceptor στο Swift προσθέτει κουπόνι Bearer μέσω adapt και επαναλαμβάνει αυτόματα το αίτημα σε URLError (απώλεια δικτύου, timeout) μέσω retry με καθυστέρηση 1 δευτερολέπτου. Ο διαχωρισμός της προσαρμογής και των επαναλήψεων επιτρέπει την ανεξάρτητη δοκιμή τους — μπορεί να γραφτεί unit test για την προσαρμογή χωρίς να επηρεάζεται η λογική retry. Σύμφωνα με στοιχεία του Alamofire (2026), το RequestInterceptor είναι ο τυπικός τρόπος κεντρικής διαχείρισης ελέγχου ταυτότητας σε έργα iOS.

Σενάρια χρήσης παρεμβολέων

Καταγραφή — το πιο συνηθισμένο σενάριο. Το Interceptor καταγράφει URL, μέθοδο, κεφαλίδες, σώμα αιτήματος και απόκρισης, χρόνο εκτέλεσης. Σε debug εκδόσεις, αυτό αντικαθιστά τα Charles Proxy και Wireshark, σε release — βοηθά αναφορές σφαλμάτων με περιβάλλον αιτήματος. Για OkHttp χρησιμοποιείται το HttpLoggingInterceptor από τη βιβλιοθήκη logging-interceptor με επίπεδα NONE, BASIC, HEADERS και BODY. Το επίπεδο BODY καταγράφει πλήρη σώματα αιτημάτων και αποκρίσεων — χρησιμοποιήστε μόνο σε debug.

Έλεγχος ταυτότητας και Refresh Token

Όταν το κουπόνι πρόσβασης λήγει, το Interceptor παρεμβαίνει στην απόκριση 401, καλεί το refresh token API και επαναλαμβάνει το αρχικό αίτημα με το νέο κουπόνι. Στο OkHttp αυτό υλοποιείται μέσω Authenticator ή προσαρμοσμένου Interceptor με έλεγχο response.code. Το Authenticator έχει πρόσβαση μόνο στις κεφαλίδες απόκρισης, το Interceptor — στο πλήρες σώμα. Στο Alamofire — μέσω RequestRetrier που επιστρέφει .retry μετά την ανανέωση κουπονιού. Σύμφωνα με στοιχεία του OWASP (2026), η αυτόματη ανανέωση κουπονιών μέσω Interceptor μειώνει τον κίνδυνο διαρροής διαπιστευτηρίων.

Προσθήκη κοινών κεφαλίδων

Content-Type, Accept-Language, User-Agent, Device-ID — κεφαλίδες που απαιτούνται σε κάθε αίτημα. Το Interceptor τις προσθέτει κεντρικά, χωρίς διπλασιασμό σε κάθε μέθοδο API. Το User-Agent σχηματίζεται μία φορά κατά την εκκίνηση της εφαρμογής: “AppName/1.0 (Android 14; Pixel 8)”. Το Accept-Language λαμβάνεται από τη γλώσσα συστήματος της συσκευής. Σύμφωνα με στοιχεία του Alamofire (2026), η κεντρική διαχείριση κεφαλίδων μέσω Interceptor μειώνει τον αριθμό σφαλμάτων λανθασμένων κεφαλίδων κατά 30%.

Βέλτιστες πρακτικές και σειρά αλυσίδας

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

Συστάσεις για εκδόσεις παραγωγής

Σε εκδόσεις release, απενεργοποιήστε την καταγραφή μέσω BuildConfig.DEBUG ή έγχυσης εξαρτήσεων. Χρησιμοποιήστε addNetworkInterceptor για προσωρινή αποθήκευση — το Network Interceptor βλέπει τις κεφαλίδες Cache-Control του διακομιστή και ερμηνεύει σωστά την πολιτική προσωρινής αποθήκευσης. Για έλεγχο ταυτότητας εφαρμόστε addInterceptor (Application) — αυτό αποτρέπει την εκ νέου παρεμβολή σε ανακατευθύνσεις προς εξωτερικούς τομείς όπου οι κεφαλίδες εξουσιοδότησης δεν πρέπει να αποστέλλονται. Δοκιμάστε κάθε Interceptor μεμονωμένα χρησιμοποιώντας MockWebServer από το okhttp-testing-support — παρεμβαίνει σε αιτήματα και επιστρέφει προετοιμασμένες αποκρίσεις, επιτρέποντας τον έλεγχο της λογικής παρεμβολέα χωρίς πραγματικό διακομιστή.

Απόδοση Interceptor

Κάθε Interceptor προσθέτει μια μικρή καθυστέρηση στον χρόνο αιτήματος. Σε μια τυπική αλυσίδα 3–4 παρεμβολέων (καταγραφή, έλεγχος ταυτότητας, συμπίεση, προσωρινή αποθήκευση) η επιβάρυνση είναι μικρότερη από 5 χιλιοστά του δευτερολέπτου ανά αίτημα. Τα προβλήματα αρχίζουν όταν το Interceptor εκτελεί λειτουργίες αποκλεισμού: σύγχρονη κλήση refresh token API, εγγραφή μεγάλων αρχείων καταγραφής σε αρχείο ή κρυπτογράφηση σώματος αιτήματος. Όλες αυτές οι λειτουργίες πρέπει να είναι ασύγχρονες ή να εκτελούνται σε νήμα παρασκηνίου. Σύμφωνα με στοιχεία της Square (2026), το OkHttp εκτελεί το Interceptor στη δεξαμενή νημάτων Dispatcher — το μπλοκάρισμα ενός παρεμβολέα καθυστερεί ολόκληρη την αλυσίδα.

• Η σειρά έχει σημασία — καταγραφή πρώτα, έλεγχος ταυτότητας πριν από επανάληψη, συμπίεση τελευταία
• Debug vs Release — HttpLoggingInterceptor μόνο σε debug εκδόσεις
• Απομόνωση — κάθε Interceptor λύνει μία εργασία (Single Responsibility)
• Ασυγχρονισμός — το Interceptor εκτελείται στο νήμα παρασκηνίου OkHttp, χωρίς να μπλοκάρει το UI