Verifichi se un metodo HTTP è sicuro o idempotente
Scopra se un metodo si può ripetere senza sorprese: put, scritto con spazi, viene letto come PUT, non sicuro ma idempotente, quindi inviarlo due volte ha lo stesso effetto previsto che inviarlo una volta. Gratis nel suo browser.
- Gratis
- Funziona nel suo browser
- Senza registrazione
- I suoi dati restano sul dispositivo
Esegui gratis nel browser
Sicuro e idempotente sono due promesse diverse
Un metodo sicuro serve a ottenere informazioni o a chiedere quali opzioni offre un server, non a cambiare qualcosa. HEAD, OPTIONS e TRACE fanno parte di questo gruppo, e ogni metodo sicuro è anche idempotente. Idempotente è una promessa più ampia: inviare più volte lo stesso messaggio ha lo stesso effetto previsto di un solo invio. PUT e DELETE la mantengono senza essere sicuri, perché salvare di nuovo lo stesso contenuto o eliminare di nuovo lo stesso elemento non aggiunge alcun effetto nuovo.
Quando controllare prima di riprovare
La domanda conta soprattutto quando la connessione cade e non si sa se il server ha ricevuto il messaggio. Prima di attivare i nuovi tentativi automatici per un metodo, lo verifichi qui: ottiene il metodo in maiuscolo, se è sicuro, se è idempotente e una breve etichetta riassuntiva. Maiuscole e spazi in eccesso non contano, quindi put diventa PUT. Un errore tipico è credere che idempotente significhi innocuo: DELETE modifica i dati, solo non due volte. I nomi sconosciuti o inventati vengono rifiutati invece che indovinati.
Interpreti correttamente i nuovi tentativi
L’idempotenza è particolarmente utile per decidere se un client automatico possa ripetere una richiesta dopo un errore di connessione. Il client potrebbe non sapere se il server ha ricevuto il primo tentativo; ripetere un metodo idempotente conserva l’effetto desiderato della richiesta. Ciò non garantisce codici di stato o corpi di risposta identici.
Per esempio, il primo DELETE può rimuovere una risorsa e restituire un esito positivo, mentre un secondo DELETE identico può segnalare che la risorsa non esiste più; lo stato finale desiderato rimane comunque lo stesso. PUT ha la medesima proprietà quando le richieste ripetute mantengono la stessa destinazione e rappresentazione.
Casi d'uso
Verifichi il middleware per nuovi tentativi
Controlli un metodo configurato prima di abilitare ripetizioni automatiche dopo errori di trasporto ambigui.
Domande frequenti
Perché DELETE è idempotente se il secondo tentativo può restituire uno stato diverso?
L’idempotenza riguarda l’effetto desiderato sul server, non risposte identiche. Richieste di eliminazione ripetute mirano allo stesso stato finale della risorsa.
Sono accettati nomi di metodo in minuscolo?
Sì. Il controllo rimuove gli spazi esterni e normalizza in maiuscolo il nome fornito prima della classificazione.
Come vengono gestiti i metodi WebDAV o personalizzati?
Vengono rifiutati come sconosciuti. Le loro proprietà devono essere ricavate dalla specifica o dal contratto applicativo che li definisce.
Che differenza c’è tra un metodo sicuro e uno idempotente?
Un metodo sicuro si limita a consultare informazioni e non chiede alcuna modifica al server. Uno idempotente può cambiare qualcosa, ma inviarlo due volte ha lo stesso effetto previsto che inviarlo una volta. PUT e DELETE sono idempotenti senza essere sicuri.
Quali metodi vengono riconosciuti?
I nove metodi standard del protocollo web e della specifica di PATCH, come PUT, PATCH, DELETE, HEAD, OPTIONS e TRACE. Maiuscole e spazi attorno al nome vengono ignorati, quindi put viene letto come PUT.
Strumenti correlati
Per sviluppatori — accesso via API
Tutto quello che vedi in questa pagina è disponibile anche via API. Questa sezione è per i team che vogliono integrarlo nei propri sistemi; chi non ne ha bisogno può semplicemente usare lo strumento qui sopra.
Endpoint
Autenticazione con Bearer token: un POST mette in coda l'attività e il risultato arriva via webhook o link firmato.
Chiamala dal tuo stack
curl -X POST https://api.kit.forhosting.com/dev2/http-method-idempotent-check \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"method":"PUT"}'const res = await fetch("https://api.kit.forhosting.com/dev2/http-method-idempotent-check", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"method": "PUT"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev2/http-method-idempotent-check",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"method": "PUT"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/http-method-idempotent-check", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"method":"PUT"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"method":"PUT"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/http-method-idempotent-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Esempio di richiesta
{
"method": "PUT"
}Esempio di risposta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev2.http_method_idempotent_check",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L'API è asincrona: ricevi subito un task_id e puoi fare polling fino a 1 richiesta al secondo.
Prezzi
Prezzo pubblicato, senza token né crediti. Se l'attività fallisce, non paghi.
Errori
| HTTP | Codice | Significato |
|---|---|---|
401 | unauthorized | Chiave API mancante o non valida: controlla l'header Authorization. |
402 | insufficient_balance | Credito esaurito: ricarica per continuare a eseguire attività. |
404 | unknown_type | Tipo di attività sconosciuto: controlla il campo type della richiesta. |
429 | rate_limited | Troppe richieste in poco tempo: rallenta e riprova tra qualche secondo. |
Note tecniche
Classifichi un metodo HTTP standard in base alle proprietà di sicurezza e idempotenza definite dalla semantica HTTP. Inserisca un metodo come GET, POST, PUT, PATCH o DELETE per ottenere il nome normalizzato, due risultati booleani distinti e una classificazione complessiva sintetica. Il controllo riconosce i nove metodi definiti nelle principali specifiche della semantica HTTP e di PATCH, ignora gli spazi esterni e le differenze tra maiuscole e minuscole e rifiuta i nomi sconosciuti, senza attribuire proprietà presunte ai metodi di estensione.
Distingua la sicurezza dall’idempotenza
Sicurezza e idempotenza esprimono garanzie diverse. Un metodo sicuro è destinato a recuperare informazioni o comunicare opzioni, non a richiedere un cambiamento di stato al server di origine. L’idempotenza è più ampia: significa che più richieste identiche producono sul server lo stesso effetto desiderato di una singola richiesta. PUT e DELETE sono idempotenti pur non essendo sicuri, perché sostituire ripetutamente una rappresentazione con la medesima rappresentazione o chiedere più volte l’eliminazione della stessa risorsa non introduce ogni volta un nuovo effetto desiderato. GET, HEAD, OPTIONS e TRACE sono sicuri. La semantica HTTP stabilisce inoltre che ogni metodo sicuro è idempotente; questi metodi ricevono quindi la classificazione combinata `safe_and_idempotent`. La risposta espone separatamente `safe` e `idempotent`, così il codice delle regole non deve dedurre una proprietà da un’etichetta. Restituisce anche il campo `classification`, utile per visualizzazione, registrazione o semplici diramazioni. Queste proprietà riguardano la semantica standard delle richieste; non garantiscono che una specifica implementazione sia priva di difetti o effetti collaterali accidentali.
Interpreti correttamente i nuovi tentativi
POST e PATCH sono classificati come né sicuri né idempotenti nelle rispettive definizioni generali. Una particolare API può progettare un’operazione POST o PATCH ripetibile, magari con una chiave di idempotenza o una richiesta condizionale, ma quel contratto applicativo non modifica la proprietà standard predefinita del metodo. Usi il risultato come base del protocollo e applichi in seguito eventuali garanzie più forti documentate esplicitamente dall’API chiamata.
Convalidi il nome prima di applicare una regola
Deducendo le proprietà di un metodo di estensione dal suo nome si rischia di autorizzare una ripetizione non sicura o bloccare un’operazione valida. Se il Suo sistema usa un metodo di estensione, consulti la specifica che lo registra o definisce e lo gestisca tramite una regola esplicita. L’algoritmo non effettua richieste di rete e non osserva server, route, cache, proxy o corpi reali. Il controllo accetta i nomi standard CONNECT, DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT e TRACE. L’input viene privato degli spazi esterni e convertito in maiuscolo, quindi valori come ` get ` e `patch` sono normalizzati senza modificarne il significato. Qualsiasi altro valore genera un errore `invalid_input`. Questo comportamento rigoroso è importante perché i token dei metodi HTTP sono estensibili: WebDAV e altri protocolli definiscono metodi aggiuntivi, mentre le API private possono introdurre token propri. È deterministico e adatto a linter, controlli della documentazione API, configurazioni di middleware per nuovi tentativi e strumenti didattici nel browser. Il browser e il gestore API condividono la stessa logica; una richiesta API applica il prezzo base pubblicato di $0.002.
Casi di integrazione
Controlli la documentazione API
Confronti i metodi scelti per gli endpoint con i documenti che dichiarano un’operazione sicura o idempotente.
Insegni la semantica HTTP
Mostri separatamente le proprietà di sicurezza e idempotenza dei metodi comuni mediante una consultazione deterministica.
Domande tecniche
Ogni metodo sicuro è anche idempotente?
Sì. La semantica HTTP definisce idempotenti i metodi sicuri, quindi GET, HEAD, OPTIONS e TRACE possiedono entrambe le proprietà.
PATCH è idempotente?
PATCH non è idempotente per impostazione predefinita. Un’API può definire un’operazione PATCH ripetibile, ma si tratta di una garanzia specifica dell’applicazione.