Recursos en la API de REST

Esto describe los recursos que conforman la API de REST oficial de GitHub Enterprise. Si tienes cualquier tipo de problema o solicitud, por favor contacta a tu administrador del sitio empresarial GitHub.

Versión actual

Predeterminadamente, todas las solicitudes a http(s)://[hostname]/api/v3 reciben la versiónv3 de la API de REST. Te alentamos a solicitar explícitamente esta versión a través del encabezado Aceptar.

Accept: application/vnd.github.v3+json

Para obtener información acerca de la API de GraphQL de GitHub, consulta la documentación de la V4. Para obtener más información acerca de migrarse a GraphQL, consulta la sección "Migrarse desde REST".

Modelo

La API desde http(s)://[hostname]/api/v3. Todos los datos se envían y reciben como JSON.

$ curl -i http(s)://[hostname]/api/v3/users/octocat/orgs

> HTTP/1.1 200 OK
> Server: nginx
> Date: Fri, 12 Oct 2012 23:33:14 GMT
> Content-Type: application/json; charset=utf-8
> Connection: keep-alive
> Status: 200 OK
> ETag: "a00049ba79152d03380c34652f2cb612"
> X-GitHub-Media-Type: github.v3
> X-RateLimit-Limit: 5000
> X-RateLimit-Remaining: 4987
> X-RateLimit-Reset: 1350085394
> X-GitHub-Enterprise-Version: enterprise-server@2.19.0
> Content-Length: 5
> Cache-Control: max-age=0, private, must-revalidate
> X-Content-Type-Options: nosniff

Los campos en blanco se incluyen como null en vez de omitirse.

Todas las marcas de tiempo se regresan en formato ISO 8601:

AAAA-MM-DDTHH:MM:SSZ

Para obtener más información acerca de las zonas horarias en las marcas de tiempo, consulta esta sección.

Representaciones de resumen

Cuando recuperas una lista de recursos, la respuesta incluye un subconjunto de los atributos para ese recurso. Esta es la representación "resumen" del recurso. (Algunos atributos son caros en términos de cómputo para que la API los proporcione. Por razones de rendimiento, la representación de resumen excluye esos atributos. Para obtener estos atributos, recupera la representación "detallada").

Ejemplo: Cuando obtienes una lista de repositorios, obtienes la representación de resumen de cada uno de ellos. Aquí, recuperamos la lista de repositorios que pertenecen a la organización octokit:

GET /orgs/octokit/repos

Representaciones detalladas

Cuando recuperas un recurso individual, la respuesta incluye habitualmente todos los atributos para ese recurso. Esta es la representación "detallada" del recurso. (Nota que la autorización algunas veces influencia la cantidad de detalles que se incluyen en la representación).

Ejemplo: Cuando obtienes un repositorio individual, obtienes la representación detallada del repositorio. Aquí, recuperamos el repositorio octokit/octokit.rb:

GET /repos/octokit/octokit.rb

La documentación proporciona un ejemplo de respuesta para cada método de la API. La respuesta de ejemplo ilustra todos los atributos que se regresan con ese método.

Autenticación

Hay dos maneras de autenticarse a través de la API v3 de GitHub Enterprise. Las solicitudes que requieren autenticación regresarán 404 Not Found, en vez de 403 Forbidden, en algunos lugares. Esto es para prevenir la fuga accidental de repositorios privados para usuarios no autorizados.

Autenticación básica

$ curl -u "username" http(s)://[hostname]/api/v3

Token de OAuth (enviado en un encabezado)

$ curl -H "Authorization: token OAUTH-TOKEN" http(s)://[hostname]/api/v3

Lee más acerca de OAuth2. Nota que los tokens de OAuth2 pueden adquirirse utilizando el flujo de la aplicación web para las aplicaciones productivas.

Llave/secreto de OAuth2

curl -u my_client_id:my_client_secret 'http(s)://[hostname]/api/v3/user/repos'

El utilizar tu client_id y client_secret no te autentica como un usuario, únicamente identifica tu aplicación de OAuth para incrementar tu límite de tasa. Los permisos se otorgan únicamente a usuarios, no a aplicaciones, y úicamente obtendrás datos que un usuario no autenticado vería. Es por esto que deberías utilizar únicamente la llave/secreto de OAuth2 en escenarios de servidor a servidor. No compartas el secreto de cliente de tu aplicación de OAuth con tus usuarios.

No podrás autenticarte utilizndo tu llave y secreto de OAuth2 si estás en modo privado, y el intentarlo regresará el mensaje 401 Unauthorized. For more information, see "Enabling private mode".

Límite de ingresos fallidos

Autenticarse con credenciales inválidas regresará el mensaje 401 Unauthorized:

$ curl -i http(s)://[hostname]/api/v3 -u foo:bar
> HTTP/1.1 401 Unauthorized

> {
>   "message": "Bad credentials",
>   "documentation_url": "https://developer.github.com/enterprise/enterprise-server@2.19/v3"
> }

Después de detectar varias solicitudes con credenciales inválidas dentro de un periodo de tiempo corto, la API rechazará temporalmente todos los intentos de autenticación para el usuario en cuestión (incluyendo aquellos con credenciales válidas) con el mensaje 403 Forbidden:

$ curl -i http(s)://[hostname]/api/v3 -u valid_username:valid_password
> HTTP/1.1 403 Forbidden

> {
>   "message": "Maximum number of login attempts exceeded. Please try again later.",
>   "documentation_url": "https://developer.github.com/enterprise/enterprise-server@2.19/v3"
> }

Parámetros

Muchos métodos de la API toman parámetros opcionales. Para las solicitudes de tipo GET, cualquier parámetro que no se haya especificado como un segmento en la ruta puede pasarse como un parámetro de secuencia de consulta HTTP:

$ curl -i "http(s)://[hostname]/api/v3/repos/vmg/redcarpet/issues?state=closed"

En este ejemplo, los valores 'vmg' and 'redcarpet' se proporcionan para los parámetros :owner y :repo en la ruta mientras que se pasa a :state en la secuencia de la consulta.

Para las solicitudes de tipo POST, PATCH, PUT, and DELETE, los parámetros que no se incluyen en la URL deben codificarse como JSON con un Content-Type de 'application/json':

$ curl -i -u username -d '{"scopes":["public_repo"]}' http(s)://[hostname]/api/v3/authorizations

Terminal raíz

Puedes emitir una solicitud de tipo GET a la terminal raíz para obtener todas las categorías de la terminal que son compatibles con la API de REST:

$ curl -u username:password http(s)://[hostname]/api/v3

IDs de nodo globales de GraphQL

Consulta la guía sobre cómo "Utilizar las ID de Nodo Global" para obtener información detallada sobre cómo encontrar las node_id a través de la API de REST y utilizarlas en las operaciones de GraphQL.

Errores de cliente

Existen tres posibles tipos de errores de cliente en los llamados a la API que reciben cuerpos de solicitud:

1. Enviar un JSON inválido dará como resultado una respuesta de tipo 400 Bad Request.

   HTTP/1.1 400 Bad Request
   Content-Length: 35
   
   {"message":"Problems parsing JSON"}
   

2. Enviar el tipo incorrecto de valores de JSON dará como resultado una respuesta de tipo 400 Bad Request.

       HTTP/1.1 400 Bad Request
       Content-Length: 40
      
       {"message":"Body should be a JSON object"}
   

3. Enviar campos inválidos dará como resultado una respuesta de tipo 422 Unprocessable Entity.

   HTTP/1.1 422 Unprocessable Entity
   Content-Length: 149
   
   {
     "message": "Validation Failed",
     "errors": [
       {
         "resource": "Issue",
         "field": "title",
         "code": "missing_field"
       }
     ]
   }
   

Todos los objetos de error tienen propiedades de campo y de recurso para que tu cliente pueda ubicar el problema. También hay un código de error para que sepas qué es lo que está mal con el campo. Estos son los posibles códigos de error de validación:

Los recursos también podría enviar errores de validación personalizados (en donde code sea custom). Custom errors will always have a message field describing the error, and most errors will also include a documentation_url field pointing to some content that might help you resolve the error.

Redireccionamientos HTTP

La API v3 utiliza redireccionamientos HTTP cuando sea adecuado. Los clientes deberán asumir que cualquier solicitud podría resultar en un redireccionamiento. Recibir un redireccionamiento HTTP no es un error y los clientes deberán seguirlo. Las respuestas de redireccionamiento tendrán un campo de encabezado de tipo Location que contendrá el URI del recurso al cual el cliente deberá repetir la solicitud.

Podrían utilizarse otros códigos de estado de redirección de acuerdo con la especificación HTTP 1.1.

Verbos HTTP

Cuando sea posible, la API v3 intentará utilizar los verbos HTTP adecuados para cada acción.

Hypermedia

Todos los recursos pueden tener una o más propiedades de *_url que los enlacen con otros recursos. Estos pretenden proporcionar las URL explícitas para que los clientes adecuados de la API no tengan que construir las URL por ellos mismos. Se recomienda ampliamente que los clientes de la API los utilicen. El hacerlo facilitará a los desarrolladores el realizar mejoras futuras a la API. Se espera que todas las URL sean plantillas de URI RFC 6570 adecuadas.

Puedes entonces expandir estas plantillas utilizando algo como la gema uri_template:

>> tmpl = URITemplate.new('/notifications{?since,all,participating}')
>> tmpl.expand
=> "/notifications"

>> tmpl.expand :all => 1
=> "/notifications?all=1"

>> tmpl.expand :all => 1, :participating => 1
=> "/notifications?all=1&participating=1"

Paginación

Las solicitudes que recuperan varios elementos se paginarán a 30 elementos predeterminadamente. Puedes especificar más páginas con el parámetro ?page. Para algunos recursos, también puedes configurar un tamaño de página personalizado de hasta 100 elementos con el parámetro ?per_page. Nota que, por razones técnicas, no todas las terminales respetan el parámetro ?per_page, consulta la sección de eventos por ejemplo.

$ curl 'http(s)://[hostname]/api/v3/user/repos?page=2&per_page=100'

Nota que la enumeración de página es basada en 1 y que el omitir el parámetro ?page regresará la primera página.

For more information on pagination, check out our guide on Traversing with Pagination.

Encabezado de enlace

El Encabezado de enlace incluye información de paginación:

Link: <http(s)://[hostname]/api/v3/user/repos?page=3&per_page=100>; rel="next",
  <http(s)://[hostname]/api/v3/user/repos?page=50&per_page=100>; rel="last"

Este ejemplo incluye un salto de línea para legibilidad.

Este encabezado de respuesta de Link contiene uno o más enlaces de relación de Hypermedia, algunos de los cuales podrían requerir expansión como plantillas URI.

Los valores de rel posibles son:

Limitación de tasas

Para las solicitudes de la API que utilizan Autenticación Básica u OAuth, puedes hacer hasta 5,000 solicitudes por hora. Las solicitudes autenticadas se asocian con el usuario autenticado, sin importar si se utilizó Autenticación Básica o un token OAuth. Esto significa que todas las aplicaciones de OAuth que autorice un usuario compartirán la misma cuota de 5,000 solicitudes por hora cuando se autentiquen con tokens diferentes que pertenezcan al mismo usuario.

Para las solicitudes no autenticadas, el límite de tasa permite hasta 60 solicitudes por hora. Las solicitudes no autenticadas se asocian con la dirección IP que las origina, y no con el usuario que realiza la solicitud.

Toma en cuenta que los límites que se mencionaron anteriormente son los límites de tasa predeterminados para una instancia de Servidor de GitHub Enterprise. Contacta a tu administrador de sitio para confirmar si los límites de tasa están habilitados y cómo se configuraron.

Nota que la API de búsqueda tiene reglas personalizadas de límite de tasa.

Los encabezados HTTP recuperados para cualquier solicitud de la API muestran tu estado actual de límite de tasa:

$ curl -i http(s)://[hostname]/api/v3/users/octocat
> HTTP/1.1 200 OK
> Date: Mon, 01 Jul 2013 17:27:06 GMT
> Status: 200 OK
> X-RateLimit-Limit: 60
> X-RateLimit-Remaining: 56
> X-RateLimit-Reset: 1372700873

Si necesitas ver la hora en un formato diferente, cualquier lenguaje de programación moderno puede ayudarte con esta tarea. Por ejemplo, si abres la consola en tu buscador web, puedes obtener fácilmente el tiempo de restablecimiento como un objeto de Tiempo de JavaScript.

new Date(1372700873 * 1000)
// => Mon Jul 01 2013 13:47:53 GMT-0400 (EDT)

Si excedes el límite de tasa, se regresará una respuesta de error:

> HTTP/1.1 403 Forbidden
> Date: Tue, 20 Aug 2013 14:50:41 GMT
> Status: 403 Forbidden
> X-RateLimit-Limit: 60
> X-RateLimit-Remaining: 0
> X-RateLimit-Reset: 1377013266

> {
>    "message": "API rate limit exceeded for xxx.xxx.xxx.xxx. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
>    "documentation_url": "https://developer.github.com/enterprise/enterprise-server@2.19/v3/#rate-limiting"
> }

Puedes revisar tu estado de límite de tasa sin incurrir en una consulta de la API.

Incrementar el límite de tasa de no autenticados para las aplicaciones de OAuth

Si tu aplicación de OAuth necesita hacer llamados no autenticados con un límite de tasa más alto, puedes pasar la ID de cliente y secreto de tu app ante la ruta de la terminal.

$ curl -u my_client_id:my_client_secret http(s)://[hostname]/api/v3/user/repos
> HTTP/1.1 200 OK
> Date: Mon, 01 Jul 2013 17:27:06 GMT
> Status: 200 OK
> X-RateLimit-Limit: 5000
> X-RateLimit-Remaining: 4966
> X-RateLimit-Reset: 1372700873

Quedarse dentro del límite de tasa

Si excedes tu límite de tasa utilizando Autenticación Básica u OAuth, es probable que puedas arreglar el problema si guardas en caché las respuestas de la API y utilizas solicitudes condicionales.

Abusar del límite de tasa

Para prorpocionar un servicio de calidad en GitHub Enterprise, los límites de tasa adicionales podrían aplicar a algunas acciones cuando se utiliza la API. Por ejemplo, utilizar la API para crear contenido rápidamente, encuestar agresivamente en vez de utilizar webhooks, hacer solicitudes múltiples concurrentes, o solicitar repetidamente datos que son caros a nivel computacional, podría dar como resultado un abuso de tasa.

El abuso de límite de tasa no pretende interferir con el uso legítimo de la API. Tus límites de tasa habituales deben ser el único límite en el cual te enfoques. Para garantizar que estás actuando como un buen ciudadano de la API, revisa nuestros lineamientos de mejores prácticas.

Si tu aplicación activa este límite de tasa, recibirás una respuesta informativa:

> HTTP/1.1 403 Forbidden
> Content-Type: application/json; charset=utf-8
> Connection: close

> {
>   "message": "You have triggered an abuse detection mechanism and have been temporarily blocked from content creation. Please retry your request again later.",
>   "documentation_url": "https://developer.github.com/enterprise/enterprise-server@2.19/v3/#abuse-rate-limits"
> }

Solicitudes condicionales

La mayoría de las respuestas regresan un encabezado de ETag. Muchas de las respuestas también regresan un encabezado de Last-Modified. Puedes utilizar los valores de estos encabezados para hacer solicitudes subsecuentes a estos recursos utilizando los encabezados If-None-Match y If-Modified-Since, respectivamente. Si el recurso no ha cambiado, el servidor regresará un 304 Not Modified.

$ curl -i http(s)://[hostname]/api/v3/user
> HTTP/1.1 200 OK
> Cache-Control: private, max-age=60
> ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
> Last-Modified: Thu, 05 Jul 2012 15:31:30 GMT
> Status: 200 OK
> Vary: Accept, Authorization, Cookie
> X-RateLimit-Limit: 5000
> X-RateLimit-Remaining: 4996
> X-RateLimit-Reset: 1372700873

$ curl -i http(s)://[hostname]/api/v3/user -H 'If-None-Match: "644b5b0155e6404a9cc4bd9d8b1ae730"'
> HTTP/1.1 304 Not Modified
> Cache-Control: private, max-age=60
> ETag: "644b5b0155e6404a9cc4bd9d8b1ae730"
> Last-Modified: Thu, 05 Jul 2012 15:31:30 GMT
> Status: 304 Not Modified
> Vary: Accept, Authorization, Cookie
> X-RateLimit-Limit: 5000
> X-RateLimit-Remaining: 4996
> X-RateLimit-Reset: 1372700873

$ curl -i http(s)://[hostname]/api/v3/user -H "If-Modified-Since: Thu, 05 Jul 2012 15:31:30 GMT"
> HTTP/1.1 304 Not Modified
> Cache-Control: private, max-age=60
> Last-Modified: Thu, 05 Jul 2012 15:31:30 GMT
> Status: 304 Not Modified
> Vary: Accept, Authorization, Cookie
> X-RateLimit-Limit: 5000
> X-RateLimit-Remaining: 4996
> X-RateLimit-Reset: 1372700873

Intercambio de recursos de origen cruzado

La API es compatible con el Intercambio de Recursos de Origen Cruzado (CORS, por sus siglas en inglés) para las solicitudes de AJAX de cualquier origen. Puedes leer la Recomendación del W3C sobre CORS, o esta introducción de la Guía de Seguridad de HTML 5.

Aquí hay una solicitud de ejemplo que se envió desde una consulta de buscador http://example.com:

$ curl -i http(s)://[hostname]/api/v3 -H "Origin: http://example.com"
HTTP/1.1 302 Found
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval

Así se ve una solicitud de prevuelo de CORS:

$ curl -i http(s)://[hostname]/api/v3 -H "Origin: http://example.com" -X OPTIONS
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Authorization, Content-Type, If-Match, If-Modified-Since, If-None-Match, If-Unmodified-Since, X-GitHub-OTP, X-Requested-With
Access-Control-Allow-Methods: GET, POST, PATCH, PUT, DELETE
Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
Access-Control-Max-Age: 86400

Rellamados de JSON-P

Puedes enviar un parámetro de ?callback a cualquier llamado de GET para envolver los resultados en una función de JSON. Esto se utiliza típicamente cuando los buscadores quieren insertar contenido de GitHub Enterprise en las páginas web evitando los problemas de dominio cruzado. La respuesta incluye la misma salida de datos que la API común, mas la información relevante del Encabezado HTTP.

$ 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
>   }
> })

Puedes escribir un agente de JavaScript para procesar la rellamada. Aquí hay un ejemplo minimalista que puedes probar:

<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>

Todos los encabezados consisten en el mismo valor de secuencia que los encabezados HTTP con una excepción notoria: El Enlace. Los encabezados de enlace se pre-analizan y se presentan como una matriz de tuplas de [url, options].

Un enlace que se ve así:

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

... se verá así en la salida de la rellamada:

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

Zonas horarias

Algunas solicitudes que crean datos nuevos, tales como aquellas para crear una confirmación nueva, te permiten proporcionar información sobre la zona horaria cuando especificas o generas marcas de tiempo. Aplicamos las siguientes reglas, en orden de prioridad, para determinar la información de la zona horaria para los llamados a la API.

• Proporcionar explícitamente una marca de tiempo de tipo ISO 8601 con información de la zona horaria
• Utilizar el encabezado de Time-Zone
• Utilizar la última zona horaria conocida del usuario
• Poner como defecto UTC en ausencia de otra información de zona horaria

Proporcionar explícitamente una marca de tiempo de tipo ISO 8601 con información de la zona horaria

Para las llamadas a la API que permitan que se especifique una marca de tiempo, utilizamos esa marca de tiempo exacta. Como ejemplo de esto, está la API de Confirmaciones.

Estas marcas de tiempo se ven más o menos como 2014-02-27T15:05:06+01:00. También, puedes ver este ejemplo como se pueden especificar las marcas de tiempo.

Utilizar el encabezado de Time-Zone

Es posible proporcionar un encabezado de Time-Zone que defina la zona horaria de acuerdo con la lista de nombres de la base de datos Olson.

$ curl -H "Time-Zone: Europe/Amsterdam" -X POST http(s)://[hostname]/api/v3/repos/github/linguist/contents/new_file.md

Esto significa que generamos una marca de tiempo para el momento en el se haga el llamado a tu API en la zona horaria que defina este encabezado. Por ejemplo, la API de Contenidos genera una confirmación de git para cada adición o cambio y utiliza este tiempo actual como la marca de tiempo. Este encabezado determinará la zona horaria que se utiliza para generar la marca de tiempo actual.

Utilizar la última zona horaria conocida del usuario

Si no se especifica ningún encabezado de Time-Zone y haces una llamada autenticada a la API, utilizaremos esta última zona horaria para el usuario autenticado. La última zona horaria conocida se actualiza cuando sea que busques el sitio web de GitHub Enterprise.

Poner como defecto UTC en ausencia de otra información de zona horaria

Si los pasos anteriores no dan como resultado ninguna información, utilizaremos UTC como la zona horaria para crear la confirmación de git.