Test delle API personalizzate

In Oracle Mobile Hub è possibile testare le interfacce API personalizzate prima che vengano distribuite utilizzando dati mock. Puoi anche testare i connettori REST utilizzando la pagina di test che supporta due modalità: Test standard e Test avanzato.

Test di un'API personalizzata Oracle Mobile Hub

Per eseguire il test dell'interfaccia API personalizzata direttamente da Oracle Mobile Hub:

  1. Accedere a Oracle Mobile Hub.
  2. Fare clic sull'icona del menu, quindi espandere Sviluppo e fare clic su Backend.
  3. Selezionare il backend mobile e fare clic su Apri.
  4. Fare clic su Impostazioni nella barra di navigazione a sinistra.
  5. Copiare l'URL dall'endpoint token SSO in URL di ambiente.
  6. Incollare l'URL copiato in una finestra del browser Web, ma non premere il tasto Invio.
  7. Copiare l'ID client nella sezione Consumer OAuth.
  8. Aggiungere un parametro della stringa di query all'URL dell'endpoint del token SSO incollato nel browser Web nel formato ?clientID=[YourClientID], quindi premere il tasto Invio. Un esempio di URL è il seguente:
    https://<YourSSOTokenEndpointURL>?clientID=<yourClientID>
    Il browser mostrerà un token OAuth Single Sign-On.
  9. Nella finestra del backend mobile fare clic sulla pagina delle interfacce API disponibile nella navigazione a sinistra. Il browser passerà dalla pagina Impostazioni alla pagina API.
  10. Fare clic su Seleziona API.
  11. Fare clic sul nome dell'interfaccia API che si desidera sottoporre a test. Viene visualizzata una nuova pagina che mostra gli endpoint API nella navigazione a sinistra, nonché le schede Richiesta e Risposta.
  12. Fare clic sull'endpoint che si desidera sottoporre a test.
  13. Nella sezione Autenticazione selezionare Token Single Sign-On dal Metodo di autenticazione.
  14. Copiare il token OAuth SSO e incollarlo nel campo Token Single Sign-On.
  15. Fare clic su Esegui test endpoint. Se tutto è corretto, il server risponde con stato 200 e dovresti vedere i dati JSON nella risposta.

Testare gli endpoint API utilizzando i dati mock

È possibile fornire dati mock nel corpo dei messaggi di richiesta e risposta durante la fase di progettazione della configurazione API. Ciò consente di esaminare il contesto di ogni chiamata senza dover utilizzare dati in tempo reale o interagire con un servizio in tempo reale. Ad esempio, per verificare se il codice gestisce correttamente un ID non valido, è possibile aggiungere un esempio nel corpo della richiesta con dati mock contenenti un ID non valido. Al termine del test, è possibile sostituire l'esempio con un altro codice per testare altri aspetti del metodo.

Nell'esempio FixItFast, i dati mock nel corpo della risposta consentono di verificare se vengono restituite le informazioni corrette sul cliente. Di seguito è riportato un esempio di dati mock che lo sviluppatore del servizio può creare per il corpo della risposta dell'operazione POST della risorsa contact nell'esempio FixItFast.
{
 "id": 20934,
 "title": "Lynn's Leaking Water Heater",
       "contact": {
       "name": "Lynn Adams",
       "street": "45 O'Connor Street",
       "city": "Ottawa",
       "postalcode": "ala1a1"
       "username":"johneta"
       }
 "status": "new",
 "driveTime": 30,
 "priority": "high",
 "createdon": "2015-04-23 18:12:03 EDT"
}

Quando si crea un'API personalizzata, viene creata automaticamente un'implementazione mock. L'implementazione mock consente di richiamare l'API dall'applicazione mobile prima di implementare il codice personalizzato. Ciò consente di sviluppare e testare contemporaneamente le applicazioni mobili e il codice personalizzato. Se si è soddisfatti della configurazione, è possibile aggiungere un'implementazione reale.

Finché non si crea la prima implementazione, l'implementazione predefinita è l'implementazione mock. Dopo aver creato un'implementazione reale, diventa l'implementazione predefinita per l'API.

Fare clic sul collegamento di navigazione Implementazioni per caricare un'implementazione o per visualizzare eventuali implementazioni esistenti. È possibile modificare l'implementazione predefinita nella pagina Implementazioni. Dopo aver caricato un'implementazione, viene visualizzato un elenco di implementazioni esistenti, che include l'implementazione mock.

Test dell'API del connettore REST

Dopo aver definito l'API del connettore REST e salvato la configurazione, si desidera verificare che sia possibile inviare una richiesta e ricevere i risultati previsti dal servizio Web. Il test di una connessione è un passo facoltativo, ma consente di risparmiare tempo identificando e risolvendo i problemi prima di finalizzare l'API del connettore. La pagina Test consente di eseguire il test di un endpoint alla volta.

Se è stato fornito un descrittore, sono disponibili due modalità di test tra cui scegliere:

  • Prove standard

    Se sono stati forniti metadati del descrittore, viene visualizzata la modalità di test standard in cui i corpi delle richieste e delle risposte vengono generati dai metadati descrittivi e visualizzati nelle schede Richiesta e Risposta. È sufficiente selezionare i parametri da sottoporre a test per i metodi GET e includere le intestazioni HTTP con cui si desidera eseguire il test.

  • Test avanzato

    È possibile perfezionare i test selezionando Test in modalità avanzata (la modalità di test immessa se è stato fornito un URL del servizio remoto). Senza metadati descrittivi, è possibile selezionare il metodo e la risorsa da sottoporre a test, includere le intestazioni HTTP da includere e creare manualmente il corpo JSON.

Test in modalità avanzata

La pagina di test avanzato consente di impostare manualmente i parametri del percorso, aggiungere intestazioni e i payload di richiesta e risposta.

Per configurare manualmente un test del connettore:

  1. Fare clic sul collegamento di navigazione Test.
  2. Se è stato fornito un descrittore, impostare Test in modalità avanzata su On.

    La pagina di test avanzato viene visualizzata automaticamente se è stato fornito un URL del servizio remoto.

  3. Selezionare il metodo HTTP di cui si desidera eseguire il test dall'elenco a discesa.
  4. Specificare i parametri del percorso risorsa nel campo URI locale in base alle esigenze a scopo di test. Ad esempio:
    directions/json?origin=los+angeles&destination=seattle

    Il campo viene preceduto automaticamente dall'URI locale definito quando si immette un nome API. Seguendo il nostro esempio, il contenuto completo del campo sarebbe simile a questo:

    myMapAPI /directions/json?origin=los+angeles&destination=seattle

    Se sono state definite regole, nel campo Regole applicate (sotto il campo Corpo) vengono visualizzati i numeri corrispondenti alle regole applicabili per l'operazione selezionata. Il campo URL remoto mostra la stringa esatta che verrà passata al servizio per il test.

  5. Aggiungere una o più intestazioni HTTP di richiesta o risposta in base alle esigenze.

    Queste intestazioni sono solo a scopo di test e non verranno aggiunte alla configurazione dell'API connettore REST.

  6. Fare clic nel campo Corpo HTTP per creare il corpo del messaggio (il payload) nell'editor di origine.
    Ad esempio:
    {
      "status":"ZERO_RESULTS",
      "routes":[ ]
    }

    Mantenere il contenuto del corpo del messaggio pertinente allo scopo del connettore, ovvero non bloccare il messaggio aggiungendo dati estranei. L'inclusione di soli dati pertinenti nel corpo del messaggio facilita la trasmissione rapida della richiesta o della risposta.

  7. Se il servizio a cui ci si sta connettendo richiede l'autenticazione, aprire la sezione Autenticazione e immettere le credenziali utente Mobile per ogni metodo di test. Se si utilizzano le credenziali di test predefinite, è possibile saltare questo passo.

    Con i criteri di sicurezza basati su SAML, l'identità dell'utente che effettua la chiamata viene propagata al servizio esterno. Per altri criteri di sicurezza quali l'autenticazione Basic HTTP e il token nome utente, le credenziali utilizzate per l'autenticazione con il servizio esterno vengono fornite negli override dei criteri come chiavi CSF. A seconda dell'operazione definita, potrebbe essere necessario immettere credenziali specifiche per ogni operazione oppure utilizzare un set di credenziali per tutti i metodi per autenticare il connettore con il servizio.

  8. Fare clic su Salva come credenziali predefinite del backend mobile corrente per salvare il nome utente e la password forniti come predefiniti.
  9. Se ci si trova nella fase di progettazione della creazione del connettore e si desidera solo verificare se gli endpoint sono validi, fare clic su Credenziali di test API Designer predefinite e selezionare un backend mobile con cui si è registrati e il relativo numero di versione.
    Facoltativamente, è possibile immettere le credenziali utente Mobile (nome utente e password).

    Queste credenziali di test predefinite sono persistenti in tutti i metodi sottoposti a test. Rimangono validi durante la sessione corrente di Mobile Hub.

  10. Fare clic su Esegui test endpoint.

    L'endpoint di test passa a Annulla test quando si fa clic su di esso. Se si desidera interrompere il test per qualsiasi motivo, fare clic su Annulla test.

    Fare clic su Reimposta per cancellare i campi e modificare i parametri di test.

  11. Fare clic su Fine al termine del test degli endpoint.