L'API Service Control fornisce un semplice
services.check
metodo per verificare queste pre condizioni. Un servizio gestito deve chiamare questo metodo regolarmente per verificare che i prerequisiti siano soddisfatti. L'attività tra il
producer di servizi e il consumer di servizi è rappresentata da un
Operation.
Il metodo services.check esegue i seguenti controlli sull'operazione:
Il progetto di producer di servizi è attivo e in uno stato integro.
Il progetto consumer del servizio è attivo e in stato integro.
Il servizio gestito è abilitato nel progetto consumer del servizio.
La chiave API è valida.
L'utilizzo della chiave API soddisfa le limitazioni associate alla chiave API, come le limitazioni relative a referrer HTTP o IP.
Il metodo services.check viene in genere chiamato dai server che implementano effettivamente il servizio. Per motivi di sicurezza e privacy,
l'API Service Control utilizza Identity and Access Management per verificare che il chiamante abbia l'autorizzazione corretta per chiamare il metodo. Per maggiori dettagli, consulta
Controllo dell'accesso all'API Service Control.
Controllo dello stato in corso…
Dopo aver implementato un servizio gestito, puoi chiamare il metodo services.check sul servizio senza ulteriore configurazione. Per ulteriori dettagli, consulta la documentazione di riferimento di services.check.
Per eseguire rapidamente esperimenti con il metodo, puoi utilizzare il comando gcurl per chiamare il metodo services.check. Per i passaggi di configurazione iniziale, consulta Introduzione all'API Service Control.
La risposta del metodo di controllo indica se tutti i controlli sono riusciti o se alcuni non sono riusciti. L'operazione è andata a buon fine se non è presente il campo checkErrors. In caso contrario, il campo checkErrors elenca i controlli non riusciti.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 UTC."],[],[],null,["# Checking Status\n\nThis page describes how to use Service Infrastructure for checking\nstatus on [managed services](/service-infrastructure/docs/glossary#managed),\n[service producers](/service-infrastructure/docs/glossary#producer),\n[service consumers](/service-infrastructure/docs/glossary#consumer), and API keys.\n\nWhen a service producer offers a service to its service consumers, it needs to\nensure that various preconditions are met, such as whether:\n\n- A service consumer has been deleted.\n- The service consumer has [enabled](/service-infrastructure/docs/glossary#enabled) the service.\n- An API key is valid.\n\nThe Service Control API provides a simple\n[`services.check`](/service-infrastructure/docs/service-control/reference/rest/v1/services/check)\nmethod to check such preconditions. A managed service should call this method on\na regular basis to ensure the preconditions are met. The activity between the\nservice producer and the service consumer is represented by an\n[`Operation`](/service-infrastructure/docs/service-control/reference/rest/v1/Operation).\nThe `services.check` method performs the following checks on the operation:\n\n- The service producer project is live and in a healthy state.\n- The service consumer project is live and in a healthy state.\n- The managed service is enabled on the service consumer project.\n- The API key is valid.\n- The use of the API key satisfies restrictions associated with the API key, such as IP or HTTP referrer restrictions.\n\nThe `services.check` method is typically called from the servers that actually\nimplement the service. For security and privacy purposes,\nthe Service Control API uses [Identity and Access Management](/iam) to verify the\ncaller has the proper permission to call the method. For details, see\n[Service Control API Access Control](/service-infrastructure/docs/service-control/access-control).\n\nChecking status\n---------------\n\nAfter you [roll out](/service-infrastructure/docs/glossary#rollout) a managed service, you can call the\n`services.check` method on the service without additional configuration. See the\n[`services.check`](/service-infrastructure/docs/service-control/reference/rest/v1/services/check)\nreference for details.\n\nTo quickly experiment with the method, you can use the `gcurl` command to call\nthe `services.check` method. See\n[Getting Started with the Service Control API](/service-infrastructure/docs/service-control/getting-started)\nfor the initial setup steps. \n\n```\ngcurl -d '{\n \"operation\": {\n \"operationId\": \"123e4567-e89b-12d3-a456-426655440000\",\n \"consumerId\": \"project:endpointsapis-consumer\",\n \"startTime\":\"2016-07-31T05:20:00Z\",\n \"operationName\":\"google.example.hello.v1.HelloService.GetHello\"\n }\n}' https://servicecontrol.googleapis.com/v1/services/endpointsapis.appspot.com:check\n{\n \"operationId\": \"123e4567-e89b-12d3-a456-426655440000\"\n}\n```\n\nThe response from the check method indicates whether all checks succeeded or\nsome checks failed. Success is indicated by the absence of\n[`checkErrors`](/service-infrastructure/docs/service-control/reference/rest/v1/services/check#CheckError)\nfield. Otherwise, the `checkErrors` field lists the failed checks."]]
