🛠️
Opencity Italia
Sviluppatori e partner tecnologici
Sviluppatori e partner tecnologici
  • Introduzione
  • Architettura
    • Pattern: microservizi
    • Pattern: event sourcing
    • Vista generale
  • Standard e convenzioni
    • Standard della piattaforma
    • Microservizi
  • Roadmap
  • Integrazioni
    • Integrazione Widget servizio (FormIO)
    • Integrazioni con il flusso delle pratiche
      • API ReST
      • Webhooks
    • Modello di integrazione con l'area personale
    • Integrazione con Intermediari di pagamento PagoPA
      • Requisiti per l'integrazione
      • Il Pagamento
        • Versione 1.0
        • Versione 2.0
      • Schema di Funzionamento
      • Configurazione dei pagamenti
        • API v1
        • API v2
      • Un pagamento in dettaglio
      • Gli stati di un pagamento
      • Processo di sviluppo
      • Implementazione di un proxy
    • Integrazione con Protocollo Informatico
      • Requisiti per l'integrazione
      • Documento digitale
        • Esempio documento con allegati non protocollato
        • Esempio documento con allegati protocollato
        • Esempio documento con campo retry_meta prodotto dal protocol proxy
        • Esempio documento con campo retry_meta modificato dal sistema di retry
        • Usecase: Il Documento originato dalle pratiche dai servizi digitali
        • Stati del documento
      • Architettura del sistema di protocollazione
      • WorkFlow sistema di protocollazione
        • Configurazione tenant e servizi
      • Protocol Proxy: Specifiche Implementative
      • Processo di sviluppo
    • Integrazioni con il Sito Istituzionale
    • Single Sign-On
      • SSO mediante oAuth2
      • SSO mediante JWT
    • Processi asincroni (job)
      • Importazione dovuti
    • Integrazione di un servizio di terze parti protetto da autenticazione
      • Esempio con GovWay
  • 👩‍💻Sviluppo
    • Multilingua
    • Temi grafici
Powered by GitBook
LogoLogo

Opencity Labs

  • Sito web
  • Product page

Developers Italia

  • Sito web
  • Area personale e Servizi Digitali

Documentazione Opencity Italia

On this page
  • Autenticazione
  • Richiesta token di autenticazione
  • Versioni delle API

Was this helpful?

Export as PDF
  1. Integrazioni
  2. Integrazioni con il flusso delle pratiche

API ReST

Le API consentono di leggere e modificare informazioni sulla piattaforma in modo programmatico.

PreviousIntegrazioni con il flusso delle praticheNextWebhooks

Last updated 13 days ago

Was this helpful?

Una API ReST, nota anche come API RESTful, è un'interfaccia di programmazione delle applicazioni (API o API web) conforme ai vincoli dello stile architetturale ReST, che consente l'interazione con servizi web RESTful. Il termine REST, coniato dall'informatico Roy Fielding, è l'acronimo di REpresentational State Transfer.

La documentazione delle API ReST della piattaforma è pubblicamente disponibile in ogni Ente all'indirizzo:

Ad esempio per il comune demo della piattaforma è possibile consultarle alla pagina:

Autenticazione

Alcune API richiedono un'autenticazione prima di essere chiamate, in questo caso un cittadino o un operatore possono usare le proprie credenziali per ottenere un token di autenticazione come segue:

Richiesta token di autenticazione

POST https://servizi.comune.bugliano.pi.it/lang/api/auth

Con questa chiamata si riceve un token di autenticazione in formato JWT, che dovrà essere inviato per tutte le successive chiamate che richiedono autenticazione come bearer token nell'header Autorization

Request Body

Name
Type
Description

username*

String

nome utente

password*

String

password

Alcuni esempi di chiamate

echo '{ "username": "my-api-user", "password": "xxxx" }' | \
http post https://servizi.comune.bugliano.pi.it/lang/api/auth

Esempio di chiamata da linea di comando con il client curl:

curl \
--header 'Content-Type: application/json' \
--data $'{\n "username": "my-api-user",\n "password": "xxxx"\n}' \
https://servizi.comune.bugliano.pi.it/lang/api/auth 

Versioni delle API

Le API sono disponibili in due versioni, la "1" e la "2". Le capacità delle API sono le stesse per le due versioni, nella versione 2 c'e' una migliore gestione del formato JSON, quindi si consiglia l'uso della versione più recente.

È possibile specificare la versione delle Api che si vanno ad interrogare, questo è possibile in 2 modi differenti:

  • tramite parametro version da passare come parametro delle GET

  • tramite parametro X-Accept-Version da specificare nell' header della richiesta

La versione di default è per retrocompatibilità la 1

Dalla versione 2 le chiavi dei valori del campo data delle applications non sono più restituite come un insieme di strighe piatto separato dal punto (.) ma come campo json con le chiavi esplose.

Nota bene: si raccomanda di specificare sempre la versione di API utilizzata, anche se è il default (1), perche' in futuro il default potrebbe cambiare.

Esempio di chiamata da linea di comando con il client :

Httpie
https://dominio/PATH/api/docsdominio
Indirizzo della documentazione delle API
Api Definition
Documentazione API
Logo
Esempio di chiamata con Postman