---
term: "Endpoint d'API"
seoTitle: "Qu'est-ce qu'un endpoint d'API ? Anatomie, exemples, bonnes pratiques"
headline: "Qu'est-ce qu'un endpoint d'API ?"
slug: endpoint-api
category: api-realtime
shortDefinition: "Un endpoint d'API est une URL spécifique où une API reçoit les requêtes pour une ressource — associé à une méthode HTTP, il définit une opération."
relatedTerms:
  - api
  - rest-api
  - api-gateway-architecture
  - auto-generated-database-apis
contrastsWith:
  - api-gateway-architecture
aboutTerms:
  - 'URL de Base'
  - 'Paramètres de Path'
  - 'Paramètres de Query'
faq:
  - question: "Qu'est-ce qu'un endpoint d'API, en termes simples ?"
    answer: "L'URL spécifique où une API reçoit les requêtes concernant une ressource — chaque endpoint est une porte d'entrée dans l'API. Une requête vers /users/42 avec la méthode GET demande les données de l'utilisateur 42 ; le même path avec DELETE demande sa suppression. L'API est le bâtiment entier ; les endpoints en sont les portes adressables."
  - question: "Quel est un exemple d'endpoint d'API ?"
    answer: "https://api.example.com/v1/users/42 — une URL de base (schéma, hôte et version), puis un path qui nomme la ressource. Équivalents réels : l'endpoint /repos/OWNER/REPO d'une plateforme d'hébergement de code, ou l'endpoint /classes/Todo qu'une application Back4app génère automatiquement pour une classe de données Todo."
  - question: "Quelle est la différence entre une API et un endpoint ?"
    answer: "L'API est le contrat entier — l'ensemble complet des règles, des ressources et des opérations qu'un service expose. Un endpoint est un point d'accès précis à l'intérieur de celui-ci. Une API expose de nombreux endpoints, et la documentation d'une API en est largement le catalogue."
  - question: "Un endpoint est-il la même chose qu'une URL ?"
    answer: "Pas tout à fait. L'endpoint s'exprime sous forme d'URL, mais l'URL n'est que l'adresse ; l'endpoint est le point d'interaction qu'elle identifie. La documentation écrit généralement les endpoints comme des paths, l'URL de base étant sous-entendue — et, à la lettre, la méthode HTTP fait partie de ce qui définit l'opération à cette adresse."
  - question: "Une même URL peut-elle correspondre à plusieurs endpoints ?"
    answer: "Oui. GET /users/42 et DELETE /users/42 partagent une URL mais sont des opérations différentes — c'est pourquoi le standard OpenAPI modélise une API comme des paths, chacun contenant plusieurs opérations indexées par méthode. Quand on compte les \"endpoints\", on compte en réalité des opérations."
  - question: "Quelle est la différence entre un endpoint et une route ?"
    answer: "Une question de point de vue. La route est la définition côté serveur — un motif de path, une méthode et une fonction handler dans votre framework. L'endpoint est l'URL exposée au client où cette route est joignable. La même chose vue des deux extrémités de la requête."
  - question: "Comment trouver les endpoints d'une API ?"
    answer: "Trois voies, par ordre de fiabilité : lire la documentation ou la spécification OpenAPI lisible par machine, qui énumère chaque path et chaque opération ; observer le trafic réel dans l'onglet réseau des outils de développement du navigateur, filtré sur fetch/XHR ; ou exercer des appels avec curl et un client d'API pour confirmer le comportement."
  - question: "Comment sécuriser un endpoint d'API ?"
    answer: "Traitez chaque endpoint comme une surface d'attaque : HTTPS uniquement, authentification sur chaque route, autorisation au moindre privilège, validation des entrées, rate limits, pagination bornée et messages d'erreur qui ne laissent rien fuiter des rouages internes. Tenez ensuite un inventaire — les endpoints \"zombies\" oubliés figurent parmi les principales failles de sécurité des API."
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'RFC 3986 — URI: Generic Syntax'
    url: 'https://datatracker.ietf.org/doc/html/rfc3986'
  - name: 'RFC 9110 — HTTP Semantics'
    url: 'https://www.rfc-editor.org/rfc/rfc9110'
  - name: 'OpenAPI Specification — Paths and Operations'
    url: 'https://spec.openapis.org/oas/latest.html#paths-object'
  - name: 'OWASP API Security Top 10'
    url: 'https://owasp.org/API-Security/'
cta:
  title: "Des endpoints que vous n'avez jamais eu à concevoir"
  text: "Créez une classe sur Back4app et ses endpoints REST existent immédiatement — URL de ressource, méthodes, authentification et permissions prises en charge par la plateforme, cohérentes sur tout votre modèle de données."
  linkText: 'Commencez gratuitement'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-10'
translationKey: api-endpoint
---

**Un endpoint d'API est une URL spécifique où une API reçoit les requêtes pour une ressource — associé à une méthode HTTP, il définit une opération.** C'est cette seconde partie que la plupart des définitions escamotent, et c'est elle qui lève la confusion classique : `GET /users/42` et `DELETE /users/42` partagent une adresse mais sont deux endpoints différents, comme une porte se comporte différemment selon que vous frappez ou que vous tournez la clé.

## Points clés

| Question | Réponse |
| --- | --- |
| La formule | URL de base + path (+ méthode) = une opération sur une ressource |
| vs. l'API | API = le contrat entier · endpoint = un point d'accès en son sein |
| Path vs. query | Le path identifie *quelle* ressource · la query dit *comment* la renvoyer |
| Nommage | Noms au pluriel, minuscules, imbrication faible — le verbe est porté par la méthode |
| Sécurité | Chaque endpoint est une surface d'attaque — y compris ceux qu'on a oubliés |

## Anatomie de l'URL d'un endpoint d'API

Chaque morceau d'une vraie URL de requête, étiqueté — selon la grammaire de la [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) :

```text
GET https://api.example.com/v1/users/42/posts?status=published&limit=20

GET                      méthode — l'action ; fait partie de l'identité de l'opération
https                    schéma — TLS, non négociable
api.example.com          hôte        ┐ l'URL de base, partagée par
/v1                      version     ┘ tous les endpoints de l'API
/users/42/posts          path — la ressource : les posts de l'utilisateur 42
        42               paramètre de path — identifie QUELLE ressource
?status=published        paramètres de query — COMMENT la renvoyer :
&limit=20                filtrer, trier, paginer (hors identité)
```

Appeler un endpoint depuis le code applicatif — le SDK compose l'URL, la méthode et l'authentification pour vous :

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// Every class gets endpoints automatically — this call hits one
const query = new Parse.Query('Todo');
query.equalTo('done', false);
query.limit(10);
const todos = await query.find();
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Every class gets endpoints automatically — this call hits one
final query = QueryBuilder<ParseObject>(ParseObject('Todo'))
  ..whereEqualTo('done', false)
  ..setLimit(10);
final response = await query.query();
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// Every class gets endpoints automatically — this call hits one
let query = Todo.query("done" == false)
  .limit(10)
let todos = try await query.find()
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// Every class gets endpoints automatically — this call hits one
val query = ParseQuery.getQuery<ParseObject>("Todo")
query.whereEqualTo("done", false)
query.limit = 10
val todos = query.find()
// Endpoint used: GET /classes/Todo?where={"done":false}&limit=10
```

## Endpoint vs. API vs. URL vs. route

La désambiguïsation à quatre termes qu'aucune page de classement ne propose :

| Terme | Ce que c'est | Vocabulaire de qui |
| --- | --- | --- |
| API | Le contrat entier : toutes les ressources, opérations et règles | De tout le monde |
| Endpoint | Un point d'accès — une URL (+ méthode) recevant les requêtes pour une ressource | La vue du consommateur |
| URL | La chaîne d'adresse qui localise l'endpoint ([RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986)) | La vue du réseau |
| Route | La définition côté serveur : motif de path + méthode + code du handler | La vue de qui implémente |

Endpoint et route sont la même chose vue des deux extrémités : un framework déclare une route, un client appelle un endpoint. Et l'[OpenAPI Specification](https://spec.openapis.org/oas/latest.html#paths-object) formalise le tableau complet — une API est un ensemble de *paths*, chaque path contient des *opérations* indexées par méthode, et "combien d'endpoints cette API a-t-elle ?" est en réalité un décompte d'opérations.

```mermaid
flowchart LR
  accTitle: Comment une requête atteint une ressource à travers un endpoint
  accDescr: Une requête client portant une méthode et une URL arrive sur l'URL de base de l'API, est appariée à la route d'un endpoint par path et méthode, passe l'authentification et la validation, puis le handler opère sur la ressource sous-jacente avant de renvoyer une réponse.
  C["Client<br/>GET /v1/users/42/posts"] --> B["URL de base de l'API<br/>appariement de route : path + méthode"]
  B --> A["Auth · validation<br/>rate limits"]
  A --> H["Handler<br/>(le code de la route)"]
  H --> R[("Ressource :<br/>les posts de l'utilisateur 42")]
  R --> H --> C
```

## Paramètres de path vs. paramètres de query

La règle qui tranche la plupart des débats de conception — **l'identité dans le path, la modification dans la query** :

| Question à laquelle le paramètre répond | Sa place | Exemple |
| --- | --- | --- |
| *Quelle* ressource ? | Path | `/users/42`, `/orders/2026-1187` |
| Quelle collection *liée* ? | Path | `/users/42/posts` |
| Filtrer les résultats ? | Query | `?status=published` |
| Trier ou paginer ? | Query | `?sort=-createdAt&limit=20` |
| Ajustements optionnels de comportement ? | Query | `?include=author&fields=title` |

La distinction a des conséquences : les paramètres de path font partie de l'identité de la ressource (et de la clé de cache) ; les paramètres de query façonnent la représentation. Une ressource joignable uniquement via des paramètres de query (`/getData?type=user&id=42`) est l'odeur de niveau 0 classique dont part l'échelle de maturité [REST](/glossary/fr/api-rest/).

## Bien nommer ses endpoints

Les consommateurs jugent une API sur sa liste d'endpoints avant d'avoir lu un mot de documentation :

| Convention | Bien | Mal |
| --- | --- | --- |
| Des noms, pas des verbes — le verbe est la méthode | `POST /orders` | `POST /createOrder` |
| Collections au pluriel | `/users`, `/users/42` | `/user/42` |
| Minuscules, avec tirets | `/purchase-orders` | `/PurchaseOrders`, `/purchase_orders` |
| Imbrication faible (un niveau) | `/users/42/posts` | `/users/42/posts/8/comments/3/likes` |
| Préfixe de version avec une politique | `/v1/…` + fenêtres de dépréciation | Casser `/v1` en silence |
| Motifs prévisibles | La même forme pour chaque ressource | Chaque ressource son dialecte |

## Sécuriser les endpoints : la checklist

Chaque endpoint est une porte, et les attaquants les essaient toutes — y compris celles que vous avez oubliées. La checklist compacte : **HTTPS uniquement** ; **authentification sur chaque endpoint** (pas d'exception "interne" joignable depuis internet) ; **autorisation par ressource**, pas seulement par API — l'utilisateur 42 qui lit `/users/43/orders` est le trou classique de broken object level authorization ; **validation des entrées** sur le path, la query et le body ; **[rate limits](/glossary/fr/rate-limiting-api/)** dimensionnés au coût de l'endpoint ; **pagination bornée** pour qu'aucun endpoint ne renvoie de collection sans plafond ; **hygiène des erreurs** (pas de stack traces, pas de fuite d'existence). Et le point que les équipes ratent : **l'inventaire**. Les endpoints "zombies" — non documentés, dépréciés mais vivants — ont leur propre entrée dans l'[OWASP API Security Top 10](https://owasp.org/API-Security/) : un endpoint dont vous ne vous souvenez pas est un endpoint que vous ne défendez pas.

## Cas d'usage courants

Là où raisonner en endpoints gagne sa place :

- **Consommer une API tierce** — le catalogue d'endpoints de la documentation *est* le produit ; maîtriser l'anatomie, c'est savoir le lire.
- **Concevoir une API publique** — des décisions de nommage, de placement des paramètres et de versionnage avec lesquelles les consommateurs vivront des années.
- **Déboguer des intégrations** — rejouer un appel du SDK comme requête brute sur l'endpoint avec curl sépare les fautes du client de celles du serveur.
- **Configurer gateway et supervision** — les [rate limits](/glossary/fr/api-gateway/), les alertes et les règles d'accès se déclarent par endpoint.
- **Audits de sécurité** — l'inventaire des endpoints est la carte de la surface d'attaque ; l'audit commence par son énumération.

## Faut-il créer un nouvel endpoint ? Matrice de décision

| Situation | Réponse |
| --- | --- |
| Nouveau type de ressource | Nouvel endpoint (`/invoices`) |
| Même ressource, résultats plus restreints | Endpoint existant + paramètres de query |
| Même URL, action différente | Même path, méthode différente |
| Un écran a besoin de cinq endpoints | Envisagez un endpoint composite — mais voyez la prolifération, plus bas |
| Représentation variante (champs, format) | Paramètre de query ou négociation de contenu, pas un nouveau path |
| Changement cassant la forme ou la sémantique | Nouveau préfixe de version, avec une fenêtre de dépréciation |

## Limites et trade-offs

- **La prolifération d'endpoints est une vraie dette.** Les endpoints par écran et par équipe s'accumulent ; chacun est de la documentation, des tests, de la supervision et de la surface d'attaque pour toujours. Peu d'endpoints bien conçus valent mieux que beaucoup d'endpoints sur mesure.
- **Les formes figées conviennent mal à certains consommateurs.** Un endpoint renvoie ce qu'il renvoie — c'est le trade-off d'[overfetching/underfetching](/glossary/fr/overfetching-et-underfetching/) auquel les API à requêtes façonnées existent pour répondre.
- **Les URL sont des contrats.** Renommer un endpoint casse tous les consommateurs ; choisissez des noms avec lesquels vous pourrez vivre, car migrer signifie versionnage, redirections et calendriers de dépréciation.
- **La méthode est invisible dans le langage courant.** "L'endpoint /users" cache s'il s'agit d'une lecture ou d'une écriture — la précision compte dans la documentation, les logs et les règles de sécurité.
- **Compter les endpoints ne mesure rien.** Une API avec 12 endpoints cohérents bat régulièrement une API avec 400 endpoints improvisés ; le signal de qualité, c'est la gouvernance, pas le volume.

## Endpoints d'API sur Back4app

Back4app est une plateforme open-source de Backend as a Service (BaaS) qui combine une base de données gérée, des API REST et GraphQL générées automatiquement, l'authentification, le stockage de fichiers et des fonctions serverless avec Cloud Code. Ici, les endpoints sont *dérivés, pas conçus* : créer une classe `Todo` expose instantanément `/classes/Todo` et `/classes/Todo/:objectId` avec le jeu complet de méthodes — le pattern des [API générées automatiquement](/glossary/fr/apis-generees-automatiquement/) — plus des endpoints permanents pour les utilisateurs, les sessions, les fichiers et les fonctions, tous partageant une seule URL de base, une authentification par clés et des permissions par classe. Les onglets de code en montrent la conséquence pratique : le SDK compose endpoint, méthode et identifiants pour vous, et la checklist ci-dessus — cohérence des noms, authentification partout, requêtes bornées, zéro zombie — arrive comme un comportement de plateforme plutôt que comme une discipline de revue de code. Les opérations sur mesure obtiennent des endpoints de la même façon : déployez une fonction Cloud Code, et `/functions/votreFonction` existe.