Sicurezza

Questo controller è sottoposto alle regole di security del sistema.
Per maggiori dettagli, fare riferimento alla sezione Authentication

Note

Le indicazioni riportate di seguito hanno lo scopo di illustrare le funzionalità e le caratteristiche di questo Web API controller.

Aliases

Questo controller è invocabile tramite altri nomi oltre a quello di default.

Ciò significa che, facendo riferimento alla grammatica di routing ({schema}://{host}/api/{version}/{controller}/{details}/{action}/{id}?{querystring}) è possibile utilizzare un fragment differente per il componente {controller}.

Di seguito è riportata la lista di tali alias per il fragment {controller}, in ordine di preferenza d'uso.

Authentication

Token JWT

Al fine di potere invocare le API REST, è necessario ottenere un token di autenticazione tramite l’apposito servizio /Auth/Login.
Per maggiori informazioni fare riferimento all'apposita sezione di questa guida.

Bearer Authentication

La "Bearer Authentication" (tradotta "autenticazione al portatore", detta anche "autenticazione token") è uno schema di autenticazione HTTP che coinvolge un token di sicurezza denominato bearer token.

Per maggiori informazioni fare riferimento all'apposita sezione di questa guida.

Identificazione dell’applicazione chiamante

Alcune delle funzioni delle API REST possono essere utilizzate solamente se (oltre ad una corretta autenticazione dell’utente) si esegue anche una dichiarazione dell’applicazione chiamante.

Per maggiori informazioni fare riferimento all'apposita sezione di questa guida.

Errori

Le actions del controller possono generare errori per i seguenti casi:

• Stato 400: query mal strutturate (es. parametri codificati non correttamente)
• Stato 401: errori di autenticazione (es. chiavi o credenziali non riconosciute)
• Stato 403: Proibito. La richiesta era valida, ma il server rifiuta l'azione. L'utente potrebbe non disporre delle autorizzazioni necessarie per una risorsa o potrebbe aver bisogno di un account di qualche tipo.
• Stato 404: Non trovato, o risorsa sconosciuta
• Stato 409: Conflitto. Indica che la richiesta non può essere elaborata a causa di conflitti nello stato corrente della risorsa, ad esempio un conflitto di modifica tra più aggiornamenti simultanei.
• Stato 500: Errore interno del del server

Gli errori sono formattati in JSON

Versioning

E’ possibile selezionare la versione dei web services tramite il token {version}

/api/{version}/{controller}/{details}/{action}/{id}?{querystring}

Il token {version} può contenere sia valori “esatti”, sia l’alias speciale “latest”, che identifica la versione più recente tra quelle esistenti nel sistema.

In linea generale si raccomanda vivamente l’utilizzo dell’alias speciale “latest”.

Qualora si desideri essere particolarmente “conservativi” ed aderenti ad una specifica versione, specificarne il nome in modo esplicito (es. “v1”).

Routing

Il sistema utilizza la seguente sintassi di routing, costituita da una sequenza di "path-tokens" (i parametri della request):

{schema}://{host}/api/{version}/{controller}/{details}/{action}/{id}?{querystring}

I tokens identificano rispettivamente:

• {host} -> HOST dell’URL
• {version} -> versione dei web services
• {controller} -> nome del servizio (controller) che si desidera invocare
• {details} -> livello opzionale di dettaglio del JSON ritornato (se pertinente)
• {action} -> azione opzionale (metodo) invocata nel controller
• {id} -> singolo argomento opzionale (parametro) di primary key del metodo nel controller, qualora esso lo preveda
• {querystring} -> parametri aggiuntivi ed eventuali "modificatori" del processo di elaborazione e serializzazione

OData

Le API REST sono internamente basate sulla tecnologia Microsoft WebAPI, e sono largamente compliant con le specifiche REST, OData v3 e OData v4.

Funzioni ed approfondimenti relativi a OData

Per maggiori approfondimenti e dettagli relativi ai criteri generali d'uso delle funzioni OData, fare riferimento alla guida di base sull'argomento

Opzioni

Le funzioni delle API REST implementate in CRM in Cloud includono un vasto set di opzioni che consentono di adattare struttura e forma dei pacchetti JSON in base alle proprie esigenze e preferenze.

Al contrario dei parametri, che vengono specificati nella route dell’URL (attraverso i tokens e la querystring), le opzioni devono invece essere passate tramite gli headers HTTP della request.

Come da RFC6648 tutte le opzioni passate tramite headers HTTP hanno nel proprio nome il prefisso custom “Crm-”.

Qualora una certa opzione non venga specificata, il sistema utilizzerà il valore di default specifico alla {version} indicata nell’URL.

Per una disquisizione completa relativa alle opzioni ed alla serializzazione polimorfica, fare riferimento alla guida generale sull'argomento

Swagger

Di seguito è possibile scaricare il descrittore JSON in formato Swagger/OpenAPI

Download Swagger descriptor