CouchDB - API HTTP
Utilizzando le intestazioni delle richieste HTTP, puoi comunicare con CouchDB. Attraverso queste richieste possiamo recuperare i dati dal database, archiviare i dati nel database sotto forma di documenti e possiamo visualizzare e formattare i documenti memorizzati in un database.
Formati di richiesta HTTP
Durante la comunicazione con il database utilizzeremo diversi formati di richiesta come get, head, post, put, delete e copy. Per tutte le operazioni in CouchDB, i dati di input e le strutture dei dati di output saranno sotto forma di oggetto JSON (JavaScript Object Notation).
Di seguito sono riportati i diversi formati di richiesta del protocollo HTTP utilizzato per comunicare con CouchDB.
GET- Questo formato viene utilizzato per ottenere un articolo specifico. Per ottenere articoli diversi, devi inviare pattern URL specifici. In CouchDB utilizzando questa richiesta GET, possiamo ottenere elementi statici, documenti di database e configurazione e informazioni statistiche sotto forma di documenti JSON (nella maggior parte dei casi).
HEAD - Il metodo HEAD viene utilizzato per ottenere l'intestazione HTTP di una richiesta GET senza il corpo della risposta.
POST- La richiesta di post viene utilizzata per caricare i dati. In CouchDB utilizzando la richiesta POST, è possibile impostare valori, caricare documenti, impostare valori di documenti e anche avviare determinati comandi di amministrazione.
PUT - Utilizzando la richiesta PUT, è possibile creare nuovi oggetti, database, documenti, viste e documenti di progettazione.
DELETE - Utilizzando la richiesta DELETE, è possibile eliminare documenti, viste e documenti di progettazione.
COPY - Utilizzando il metodo COPY, è possibile copiare documenti e oggetti.
Intestazioni richieste HTTP
Le intestazioni HTTP dovrebbero essere fornite per ottenere il formato e la codifica corretti. Durante l'invio della richiesta al server CouchDB, è possibile inviare le intestazioni della richiesta HTTP insieme alla richiesta. Di seguito sono riportate le diverse intestazioni delle richieste Http.
Content-type- Questa intestazione viene utilizzata per specificare il tipo di contenuto dei dati che forniamo al server insieme alla richiesta. Per lo più il tipo di contenuto che inviamo insieme alla richiesta sarà di tipo MIME o JSON (application / json). Si consiglia vivamente di utilizzare il tipo di contenuto su una richiesta.
Accept- Questa intestazione viene utilizzata per specificare il server, l'elenco dei tipi di dati che il client può comprendere, in modo che il server invii la sua risposta utilizzando quei tipi di dati. In genere qui è possibile inviare l'elenco dei tipi di dati MIME accettati dal client, separati da due punti.
Sebbene non sia necessario utilizzare Accept nelle query di CouchDB, si consiglia vivamente di garantire che i dati restituiti possano essere elaborati dal client.
Intestazioni di risposta
Queste sono le intestazioni della risposta inviata dal server. Queste intestazioni forniscono informazioni sul contenuto inviato dal server come risposta.
Content-type- Questa intestazione specifica il tipo MIME dei dati restituiti dal server. Per la maggior parte delle richieste, il tipo MIME restituito è text / plain.
Cache-control- Questa intestazione suggerisce al client di trattare le informazioni inviate dal server. CouchDB restituisce principalmente il must-revalidate, che indica che le informazioni dovrebbero essere riconvalidate se possibile.
Content-length - Questa intestazione restituisce la lunghezza del contenuto inviato dal server, in byte.
Etag - Questa intestazione viene utilizzata per mostrare la revisione di un documento o di una vista.
Codici di stato
Di seguito è riportato il formato tabulare del codice di stato inviato dall'intestazione http e la sua descrizione.
Sr.No. | Codice di stato e descrizione |
---|---|
1 | 200 − OK Questo stato verrà emesso quando una richiesta è stata completata con successo. |
2 | 201 − Created Questo stato verrà emesso quando viene creato un documento. |
3 | 202 − Accepted Questo stato verrà emesso quando una richiesta viene accettata. |
4 | 404 − Not Found Questo stato verrà emesso quando il server non è in grado di trovare il contenuto richiesto. |
5 | 405 − Resource Not Allowed Questo stato viene emesso quando il tipo di richiesta HTTP utilizzato non è valido. |
6 | 409 − Conflict Questo stato viene emesso ogni volta che si verifica un conflitto di aggiornamento. |
7 | 415 − Bad Content Type Questo stato indicava che il tipo di contenuto richiesto non è supportato dal server. |
8 | 500 − Internal Server Error Questo stato viene emesso ogni volta che i dati inviati nella richiesta non sono validi. |
Percorsi URL HTTP
Esistono alcuni percorsi URL che consentono di interagire direttamente con il database. Di seguito è riportato il formato tabulare di tali percorsi URL.
Sr.No. | URL e operazione |
---|---|
1 | PUT /db Questo URL viene utilizzato per creare un nuovo database. |
2 | GET /db Questo URL viene utilizzato per ottenere le informazioni sul database esistente. |
3 | PUT /db/document Questo URL viene utilizzato per creare un documento / aggiornare un documento esistente. |
4 | GET /db/document Questo URL viene utilizzato per ottenere il documento. |
5 | DELETE /db/document Questo URL viene utilizzato per eliminare il documento specificato dal database specificato. |
6 | GET /db/_design/design-doc Questo URL viene utilizzato per ottenere la definizione di un documento di progettazione. |
7 | GET /db/_design/designdoc/_view/view-name Questo URL viene utilizzato per accedere alla vista, nome-vista dal documento di progettazione dal database specificato. |