Pontos de extremidade da API REST para pesquisa

Sobre a pesquisa

Você pode usar a API REST para pesquisar o item específico que deseja localizar. Por exemplo, você pode encontrar um usuário ou um arquivo específico em um repositório. Pense nisso da mesma forma que você pensa em realizar uma pesquisa no Google. Ele é projetado para ajudá-lo a encontrar o resultado que você está procurando (ou talvez os poucos resultados que você está procurando). Assim como pesquisar no Google, às vezes, você quer ver algumas páginas com resultados de pesquisa para que você possa encontrar o item que melhor atenda às suas necessidades. Para atender a essa necessidade, a API REST do GitHub Enterprise Cloud fornece até mil resultados para cada pesquisa.

Você pode restringir sua pesquisa usando as consultas. Para saber mais sobre a sintaxe de consulta de pesquisa, confira Pontos de extremidade da API REST para pesquisa.

Resultados da pesquisa de classificação

A menos que outra opção de ordenamento seja fornecida como um parâmetro de consulta, os resultados são ordenados pela melhor correspondência e em ordem decrescente. Vários fatores são combinados para impulsionar o item mais relevante para a parte superior da lista de resultados.

Limite de taxa

A API REST tem um limite de taxa personalizado para pesquisa. Para solicitações autenticadas, você pode fazer até 30 solicitações por minuto para todos os pontos de extremidade de pesquisa, exceto para o ponto de extremidade Código de pesquisa. O ponto de extremidade "Código de pesquisa" exige que você se autentique e limite você a 10 solicitações por minuto. Para solicitações não autenticadas, o limite de taxa permite que você faça até dez solicitações por minuto.

Para obter informações sobre como determinar o status do limite de taxa atual, confira Limite de Taxa.

Criar uma consulta de pesquisa

Cada ponto de extremidade para pesquisa usa parâmetros de consulta para executar pesquisas no GitHub Enterprise Cloud. Consulte os pontos de extremidade individuais para obter exemplos que incluem o ponto de extremidade e os parâmetros de consulta.

Uma consulta pode conter qualquer combinação de qualificadores de pesquisa compatíveis em GitHub Enterprise Cloud. O formato da consulta de pesquisa é:

SEARCH_KEYWORD_1 SEARCH_KEYWORD_N QUALIFIER_1 QUALIFIER_N

Por exemplo, se você quiser pesquisar todos os repositórios pertencentes a defunkt que contêm a palavra GitHub e Octocat no arquivo README, usará a seguinte consulta com o ponto de extremidade dos repositórios de pesquisa:

GitHub Octocat in:readme user:defunkt

Observação: lembre-se de usar o codificador de HTML preferencial da sua linguagem para construir cadeias de consulta. Por exemplo:

// JavaScript
const queryString = 'q=' + encodeURIComponent('GitHub Octocat in:readme user:defunkt');

Confira Pesquisar no GitHub para ver uma lista completa de qualificadores disponíveis, o formato deles e um exemplo de como usá-los. Para obter informações sobre como usar operadores para corresponder a quantidades e datas específicas ou excluir resultados específicos, confira Noções básicas de sintaxe de pesquisa.

Limitações no tamanho da consulta

Você não pode usar consultas que:

• Têm tamanho superior a 256 caracteres (não incluindo operadores ou qualificadores).
• Têm mais de cinco operadores AND, OR ou NOT.

Estas consultas de pesquisa irão retornar uma mensagem de erro "Ocorreu uma falha na validação".

Limites de escopo de pesquisa

Para manter a API REST rápida para todos, limitamos o número de repositórios que uma consulta pesquisará. A API REST encontrará até 4.000 repositórios que correspondem aos filtros e retornam resultados desses repositórios.

Tempo esgotado e resultados incompletos

Para manter a API REST rápida para todos, limitamos o tempo em que as consultas individuais podem ser executadas. Para consultas que excedem o limite de tempo, a API retorna as correspondências que já foram encontradas antes do tempo limite, e a resposta tem a propriedade incomplete_results definida como true.

Atingir um tempo limite não significa necessariamente que os resultados da pesquisa estão incompletos. É possível que mais resultados tenham sido, mas também é possível que não.

Erros de acesso ou resultados de pesquisa ausentes

Você precisará se autenticar com sucesso e ter acesso aos repositórios nas consultas de pesquisa, caso contrário, verá um erro 422 Unprocessable Entry com uma mensagem "Falha na validação". Por exemplo, a pesquisa falhará se a consulta incluir qualificadores repo:, user: ou org: que solicitam recursos aos quais você não tem acesso quando entra no GitHub.

Quando a consulta de pesquisa solicitar vários recursos, a resposta conterá apenas os recursos aos quais você tem acesso e não fornecerá uma mensagem de erro listando os recursos que não foram retornados.

Por exemplo, se a consulta de pesquisa pesquisar os repositórios octocat/test e codertocat/test, mas você só tiver acesso ao octocat/test, a resposta mostrará os resultados da pesquisa para o octocat/test e nada para o codertocat/test. Este comportamento imita como a pesquisa que funciona no GitHub.

Metadados da correspondência de texto

No GitHub, você pode usar o contexto fornecido por snippets de código e destaques em resultados de pesquisa. Os pontos de extremidade para pesquisa retornam metadados adicionais que permitem que você destaque os termos de pesquisa correspondentes ao exibir resultados de busca.

As solicitações podem optar por receber esses fragmentos de texto na resposta, e cada fragmento é acompanhado de ajustes numéricos que identificam a localização exata de cada termo de pesquisa correspondente.

Para inserir esses metadados nos resultados da pesquisa, especifique o tipo de mídia text-match no cabeçalho Accept.

application/vnd.github.text-match+json

Ao fornecer o tipo de mídia text-match, você receberá uma chave extra no conteúdo JSON chamado text_matches que fornece informações sobre a posição dos termos de pesquisa no texto e a property que inclui o termo de pesquisa. Dentro da matriz text_matches, cada objeto inclui os seguintes atributos:

Nome	Descrição
object_url	A URL para o recurso que contém uma propriedade de string que corresponde a um dos termos de pesquisa.
object_type	O nome do tipo de recurso que existe na object_url especificada.
property	O nome de uma propriedade do recurso que existe em object_url. Esta propriedade é uma string que corresponde a um dos termos de pesquisa. (No JSON retornado da object_url, o conteúdo completo de fragment será encontrado na propriedade com esse nome).
fragment	Um subconjunto do valor de property. Este é o fragmento de texto que corresponde a um ou mais dos termos de pesquisa.
matches	Uma matriz de um ou mais termos de pesquisa que estão presentes em fragment. Os índices (ou seja, "ajustes") são relativos ao fragmento. (Eles não são relativos ao conteúdo completo de property).

Exemplo

Usando um comando curl e o exemplo de pesquisa de problemas acima, nossa solicitação de API ficaria assim:

curl -H 'Accept: application/vnd.github.text-match+json' \
'https://api.github.com/search/issues?q=windows+label:bug \
+language:python+state:open&sort=created&order=asc'

A resposta incluirá uma matriz text_matches para cada resultado da pesquisa. No JSON abaixo, temos dois objetos na matriz text_matches.

A primeira correspondência de texto ocorreu na propriedade body do problema. Vemos um fragmento de texto a partir do texto do problema. O termo de pesquisa (windows) aparece duas vezes nesse fragmento, e temos os índices de cada ocorrência.

A segunda correspondência de texto ocorreu na propriedade body de um dos comentários do problema. Nós temos a URL do comentário do problema. E, evidentemente, vemos um fragmento de texto do comentário. O termo de pesquisa (windows) aparece uma vez nesse fragmento.

{
  "text_matches": [
    {
      "object_url": "https://api.github.com/repositories/215335/issues/132",
      "object_type": "Issue",
      "property": "body",
      "fragment": "comprehensive windows font I know of).\n\nIf we can find a commonly
      distributed windows font that supports them then no problem (we can use html
      font tags) but otherwise the '(21)' style is probably better.\n",
      "matches": [
        {
          "text": "windows",
          "indices": [
            14,
            21
          ]
        },
        {
          "text": "windows",
          "indices": [
            78,
            85
          ]
        }
      ]
    },
    {
      "object_url": "https://api.github.com/repositories/215335/issues/comments/25688",
      "object_type": "IssueComment",
      "property": "body",
      "fragment": " right after that are a bit broken IMHO :). I suppose we could
      have some hack that maxes out at whatever the font does...\n\nI'll check
      what the state of play is on Windows.\n",
      "matches": [
        {
          "text": "Windows",
          "indices": [
            163,
            170
          ]
        }
      ]
    }
  ]
}