This page is a translated version of the page API:Etiquette and the translation is 34% complete.
Outdated translations are marked like this.

This page contains the best practices that should be followed when using the API.

Comportamento

Limiti di richieste

Non c'è un limite fisso sulle richieste in lettura, ma ti chiediamo di essere così gentile da non tentare di interrompere il servizio di un sito. Molti amministratori di sistema si riservano il diritto di bloccarti senza tanti complimenti se metti a repentaglio la stabilità del loro sito.

Making your requests in series rather than in parallel, by waiting for one request to finish before sending a new request, should result in a safe request rate. It is also recommended that you ask for multiple items in one request by:

  • Using the pipe character (|) whenever possible e.g. titles=PageA|PageB|PageC, instead of making a new request for each title.
  • Using a generator instead of making a request for each result from another request.
  • Use GZip compression when making API calls by setting Accept-Encoding: gzip to reduce bandwidth usage.

Requests which make edits, modify state or otherwise are not read-only requests, are subject to rate limiting. The exact rate limit being applied might depend on the type of action, your user rights and the configuration of the website you are making the request to. The limits that apply to you can be determined by accessing the action=query&meta=userinfo&uiprop=ratelimits API endpoint.



When you hit the request rate limit you will receive a API error response with the error code ratelimited. When you encounter this error, you may retry that request, however you should increase the time between subsequent requests. A common strategy for this is Exponential backoff.

Analizzare le revisioni

Sebbene sia possibile ottenere dei risultati da uno specifico numero di revisione utilizzando il parametro revid, questa è un'operazione dispendiosa per i server. Per recuperare una revisione specifica, utilizzare il parametro oldid. Ad esempio:


Il parametro maxlag

Se il tuo compito non richiede interazione, ad esempio se l'utente non è in attesa del risultato, dovresti utilizzare il parametro maxlag. The value of the maxlag parameter should be an integer number of seconds. Per esempio:


Questo preverrà che il tuo lavoro continui a rimanere in esecuzione mentre il carico sui server è alto. Un valore alto significa un comportamento più aggressivo, un valore basso è più apprezzato.

See Manual:Maxlag parameter for more details.

User-Agent header

It is best practice to set a descriptive User Agent header. To do so, use User-Agent: clientname/version (contact information e.g. username, email) framework/version.... For example in PHP:

ini_set('user_agent', 'MyCoolTool/1.1 (https://example.org/MyCoolTool/; MyCoolTool@example.org) UsedBaseLibrary/1.4');

Non copiare semplicemente l'user-agent di un browser web popolare. Questo fa sì che laddove emerga un problema sia facile tracciare da dove provenga.

If you are calling the API from browser-based JavaScript, you may not be able to influence the User-Agent header, depending on the browser. To work around this, use the Api-User-Agent header.

Data formats

All new API users should use JSON . Vedi API:Data_formats per i dettagli.

Performance

Downloading data in bulk is not always extremely efficient using the Action API. On Wikimedia wikis, there are faster ways to get data in bulk, see m:Research:Data and wikitech:Portal:Data Services for more details.

Other notes

If your requests obtain data that can be cached for a while, you should take steps to cache it, so you don't request the same data over and over again. Some clients may be able to cache data themselves, but for others (particularly JavaScript clients), this is not possible.

Whenever you're reading data from the web service API, you should try to use GET requests if possible, not POST, as the latter are not cacheable.

Vedi anche