Skip to main content

Utilisation de CORS et JSONP pour effectuer des requêtes cross-origin

Vous pouvez effectuer des requêtes d’API entre domaines à l’aide du partage de ressources cross-origin (CORS) et des rappels JSONP.

À propos des requêtes cross-origin

Une requête cross-origin est une requête adressée à un domaine différent de celui qui est à l’origine de la demande. Pour des raisons de sécurité, la plupart des navigateurs web bloquent les demandes cross-origin. Vous pouvez utiliser le partage de ressources cross-origin (CORS) et des rappels JSONP pour effectuer des requêtes cross-origin.

Partage des ressources cross-origin (CORS)

L’API REST prend en charge le partage de ressources cross-origin (CORS) pour les demandes AJAX de toute origine. Pour plus d’informations, consultez la Recommandation CORS W3C et le Guide de sécurité HTML 5

Voici un exemple de demande envoyée par un navigateur qui atteint http://example.com :

$ curl -I http(s)://HOSTNAME/api/v3 -H "Origin: http://example.com"
HTTP/2 302
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag, Link, x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval

Voici à quoi ressemble la demande préliminaire CORS :

$ curl -I http(s)://HOSTNAME/api/v3 -H "Origin: http://example.com" -X OPTIONS
HTTP/2 204
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Authorization, Content-Type, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, X-Requested-With
Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE
Access-Control-Expose-Headers: ETag, Link, x-ratelimit-limit, x-ratelimit-remaining, x-ratelimit-reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
Access-Control-Max-Age: 86400

Rappels JSON-P

Vous pouvez envoyer un paramètre ?callback à n’importe quel appel GET pour que les résultats s’encapsulent dans une fonction JSON. Cette technique est généralement utilisée lorsque les navigateurs doivent incorporer du contenu GitHub Enterprise Server dans des pages web et éviter les problèmes interdomaines. La réponse inclut la même sortie de données que l’API classique, ainsi que les informations d’en-tête HTTP pertinentes.

$ curl http(s)://HOSTNAME/api/v3?callback=foo

> /**/foo({
>   "meta": {
>     "status": 200,
>     "x-ratelimit-limit": "5000",
>     "x-ratelimit-remaining": "4966",
>     "x-ratelimit-reset": "1372700873",
>     "Link": [ // pagination headers and other links
>       ["http(s)://HOSTNAME/api/v3?page=2", {"rel": "next"}]
>     ]
>   },
>   "data": {
>     // the data
>   }
> })

Vous pouvez écrire un gestionnaire JavaScript pour traiter le rappel. Voici un exemple minimal que vous pouvez essayer :

<html>
<head>
<script type="text/javascript">
function foo(response) {
  var meta = response.meta;
  var data = response.data;
  console.log(meta);
  console.log(data);
}

var script = document.createElement('script');
script.src = 'http(s)://HOSTNAME/api/v3?callback=foo';

document.getElementsByTagName('head')[0].appendChild(script);
</script>
</head>

<body>
  <p>Open up your browser's console.</p>
</body>
</html>

Tous les en-têtes ont la même valeur de chaîne que les en-têtes HTTP, à l’exception de Link. Les en-têtes Link, préanalysés automatiquement, se présentent sous la forme d’un tableau de tuples [url, options].

Par exemple, un lien qui ressemble à ceci :

Link: <url1>; rel="next", <url2>; rel="foo"; bar="baz"

se présente ainsi dans la sortie de rappel :

{
  "Link": [
    [
      "url1",
      {
        "rel": "next"
      }
    ],
    [
      "url2",
      {
        "rel": "foo",
        "bar": "baz"
      }
    ]
  ]
}