GraphQL en REST: behoeften, kosten en rechten vergelijken

In het kort

GraphQL laat clients velden uit een getypeerd schema kiezen en kan REST aanvullen. Geen van beide is voor elke taak automatisch sneller of veiliger.

Lege beveiligde gang met servers en netwerken Illustratie · fictieve scène
In dit artikel

Aanvraag en kosten begrijpen

Het voorbeeld gebruikt een fictief schema: customer, orders en total moeten in de echte API bestaan. Eén aanvraag kan meerdere serverlezingen veroorzaken. REST kan ook aangepaste antwoorden bieden. Eén HTTP-eindpunt is gebruikelijk bij GraphQL, maar geen verplichting voor elke architectuur.

query RecentOrders($id: ID!) {
  customer(id: $id) {
    name
    orders(first: 5) {
      nodes { id total }
    }
  }
}

Een representatieve taak vergelijken

  • Meet bytes, vertraging, fouten en serverwerk bij hetzelfde scherm, dezelfde rechten en realistische volumes.
  • Controleer paginering, gebundelde lezingen tegen N+1, caching en scheiding tussen accounts.
  • Beoordeel schemawijzigingen, oudere clients en beheerlast. REST behouden kan eenvoudiger zijn.

Rechten en belasting begrenzen

Authenticeer aanvragen en autoriseer objecten en velden in de bedrijfslogica. Begrens lijsten, diepte, aliassen, gebundelde bewerkingen en geschatte kosten. Aanvraagfrequentie alleen beschrijft de belasting niet. Introspectie verbergen vervangt deze maatregelen niet; test weigeringen en gedeeltelijke antwoorden.

Primaire bronnen

Beheer het GraphQL-schema en de querykosten.

GraphQL stelt clients in staat velden te selecteren, maar die flexibiliteit vereist object- en veldautorisatie. Een limiet voor grootte of diepte alleen vervangt niet het meten van de belasting die een query veroorzaakt.

  • Test gevoelige velden en objecten die eigendom zijn van een ander account.
  • Beperk en observeer de kosten, diepte en het aanvraagvolume voor de service.
  • Wijzigingen in het versiebeheerschema en test oudere clients.

Primaire bron: OWASP — GraphQL Cheat Sheet. Verwante methode: lees de praktische gids.

ETag, HTTP-cache en gelijktijdige wijzigingen

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

REST and GraphQL: separate representation and authorisation

An HTTP ETag applies to a selected representation. It is neither permission for every returned object nor a universal consistency contract for GraphQL entities.

  • Define which response variants have their own validators.
  • Test object and field access independently from HTTP conditions.
  • Do not automatically apply the PUT scenario to a GraphQL mutation; specify its concurrency contract.

Explore ETag comparisons and the simulator →

References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3