REST vs GraphQL vs gRPC — πότε θα επιλέγατε το καθένα;

Question

IT Interview Practice · Accepted Answer

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

## Τα τρία με μια ματιά

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

Προσανατολισμένο στους πόρους πάνω από απλό HTTP. **Επιλέξτε το** για δημόσια APIs, υπηρεσίες CRUD, και οτιδήποτε ωφελείται από HTTP caching, πανταχού παρουσία, και απλότητα. Οι αδυναμίες του είναι το **over-fetching** (παίρνετε ολόκληρο το `/users/42` ακόμη κι αν χρειάζεστε ένα πεδίο) και το **under-fetching** (το πρόβλημα `N+1`: φέρτε έναν user, μετά κάντε loop για να φέρετε κάθε order).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

Ένα μοναδικό endpoint όπου ο **client καθορίζει ακριβώς τι θέλει** σε ένα query, λύνοντας το over/under-fetching. **Επιλέξτε το** για πλούσια frontends (ειδικά mobile, όπου τα round trips είναι δαπανηρά) και όταν πολλοί clients χρειάζονται διαφορετικά σχήματα των ίδιων δεδομένων.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
Ανταλλαγές: το HTTP caching είναι δυσκολότερο (όλα είναι `POST` προς το `/graphql`), και ένας αφελής resolver μπορεί να κρύψει δαπανηρά `N+1` queries στη βάση δεδομένων.

## gRPC

RPC με προτεραιότητα στο συμβόλαιο (contract-first) χρησιμοποιώντας **Protobuf** πάνω από **HTTP/2**. Δυαδικό και multiplexed, οπότε είναι γρήγορο και συμπαγές με υποστήριξη streaming. **Επιλέξτε το** για **εσωτερική επικοινωνία service-to-service** σε ένα backend microservices όπου οι επιδόσεις και η αυστηρή τυποποίηση έχουν σημασία. Αδυναμία: κακή υποστήριξη browser (χρειάζεται proxy όπως το grpc-web) και δεν είναι αναγνώσιμο από άνθρωπο.

## Επιλέγοντας

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## Γιατί έχει σημασία

Σε επίπεδο senior, οι συνεντευξιαστές νοιάζονται λιγότερο για τους ορισμούς και περισσότερο για το αν μπορείτε να **δικαιολογήσετε μια επιλογή έναντι περιορισμών** — αυτή η ερώτηση είναι στην ουσία "μπορείς να ταιριάξεις μια τεχνολογία με ένα πρόβλημα αντί να κυνηγάς το hype;". Οι πιο δυνατές απαντήσεις αγκυρώνονται στον πόνο που λύνει η καθεμία: το GraphQL υπάρχει για να σκοτώσει το over/under-fetching για απαιτητικά frontends, το gRPC υπάρχει για να κάνει τις εσωτερικές κλήσεις υπηρεσιών γρήγορες και αυστηρά τυποποιημένες, και το REST παραμένει η προεπιλογή επειδή το HTTP caching, τα εργαλεία, και η καθολική εξοικείωση είναι τεράστια πρακτικά πλεονεκτήματα για δημόσια και CRUD-style APIs. Κρίσιμα, ένας senior μηχανικός σημειώνει ότι **δεν είναι το ένα ή το άλλο** — μια συνηθισμένη αρχιτεκτονική είναι REST ή GraphQL στο δημόσιο edge με gRPC ανάμεσα στα backend microservices — και ονομάζει τις συγκεκριμένες ανταλλαγές (τους κινδύνους caching και `N+1` του GraphQL, την αδύναμη ιστορία browser του gRPC). Αυτός ο συλλογισμός για την καταλληλότητα και το κόστος, όχι η ικανότητα απαγγελίας χαρακτηριστικών, είναι το σήμα.

Τα τρία με μια ματιά

REST

GraphQL

gRPC

Επιλέγοντας

Γιατί έχει σημασία

Σχετικές ερωτήσεις