API personalizadas de prueba

En Oracle Mobile Hub, puede probar las API personalizadas antes de desplegarlas utilizando datos ficticios. También puede probar los conectores de REST utilizando la página de prueba que soporta dos modos: Prueba estándar y Prueba avanzada.

Prueba de una API personalizada de Oracle Mobile Hub

Para probar la API personalizada directamente desde Oracle Mobile Hub:

Inicie sesión en Oracle Mobile Hub.
Haga clic en el icono de menú y, a continuación, amplíe Desarrollo y haga clic en Backends.
Seleccione su backend móvil y haga clic en Abrir.
Haga clic en Configuración en la barra de navegación izquierda.
Copie la URL del punto final del token de SSO ubicado en las URL del entorno.
Pegue la URL copiada en una ventana del explorador web, pero no pulse la tecla Intro.
Copie su ID de cliente en la sección Consumidor de OAuth.
Agregue un parámetro de cadena de consulta a la URL de punto final del token de SSO que haya pegado en su explorador web con el formato?clientID=[YourClientID] y, a continuación, pulse la tecla Intro. Un ejemplo de la dirección URL sería el siguiente:
```
https://<YourSSOTokenEndpointURL>?clientID=<yourClientID>
```
El explorador le mostrará un token de OAuth de Single Sign-On.
En la ventana de backend móvil, haga clic en la página API ubicada en la navegación izquierda. El explorador cambiará de la página Configuración a la página API.
Haga clic en Seleccionar API.
Haga clic en el nombre de API que desea probar. Se abre una nueva página que muestra los puntos finales de API en la navegación izquierda, así como los separadores Solicitud y Respuesta.
Haga clic en el punto final que desea probar.
En la sección Authentication (Autenticación ), seleccione Single Sign-on Token (Token de inicio de sesión único) en Authentication Method (Método de autenticación).
Copie el token OAuth de SSO y péguelo en el campo Token de Conexión Única.
Haga clic en Probar Punto Final. Si todo es correcto, el servidor responde con el estado 200 y debería ver los datos de JSON en la respuesta.

Prueba de puntos finales de API mediante datos de ficticio

Puede proporcionar datos de tiempo en los cuerpos de mensajes de solicitud y respuesta durante la fase de diseño de la configuración de API. Esto permite examinar el contexto de cada llamada sin tener que utilizar datos en tiempo real ni interactuar con un servicio en tiempo real. Por ejemplo, para probar si el código maneja correctamente un identificador no válido, puede agregar un ejemplo en el cuerpo de la solicitud con datos de ficticio que contengan un identificador no válido. Cuando termine la prueba, puede sustituir el ejemplo por otro código para probar algún otro aspecto del método.

En el ejemplo de FixItFast, los datos de ficticio en el cuerpo de la respuesta permiten verificar si se devuelve la información correcta del cliente. A continuación se muestra un ejemplo de datos de retraso que el desarrollador de servicios podría crear para el cuerpo de respuesta de la operación POST del recurso contact en el ejemplo de 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"
}

Al crear una API personalizada, se crea automáticamente una implantación ficticia. La implantación de ficticio permite llamar a la API desde la aplicación móvil antes de implantar el código personalizado. Esto permite desarrollar y probar las aplicaciones móviles y el código personalizado simultáneamente. Si está satisfecho con la configuración, puede agregar una implantación real.

Hasta que no cree su primera implantación, la implantación por defecto es la implementación de ficticio. Después de crear una implantación real, se convierte en la implementación por defecto de la API.

Haga clic en el enlace de navegación Implantaciones para cargar una implantación o para ver las implantaciones existentes. Puede cambiar la implantación por defecto en la página Implantaciones. Después de cargar una implantación, verá una lista de implantaciones existentes, que incluye la implantación de ficticio.

Probar la API de conector de REST

Ahora que ha definido la API de conector de REST y ha guardado la configuración, desea verificar que puede enviar una solicitud y recibir los resultados esperados del servicio web. Probar una conexión es un paso opcional, pero puede ahorrar tiempo identificando y corrigiendo problemas ahora antes de finalizar la API de conector. La página Prueba permite probar un punto final a la vez.

Si ha proporcionado un descriptor, tiene dos modos de prueba entre los que elegir:

Pruebas estándar

Si ha proporcionado metadatos de descriptor, se muestra el modo de prueba estándar en el que se generan los cuerpos de solicitud y respuesta de los metadatos descriptivos y se muestran en los separadores Solicitud y Respuesta. Lo único que tiene que hacer es seleccionar los parámetros que se van a probar para los métodos GET e incluir las cabeceras HTTP que desee probar.
Pruebas avanzadas

Puede acotar las pruebas seleccionando Prueba en Modo Avanzado (el modo de prueba que introduzca si ha proporcionado una URL de servicio remoto). Sin metadatos descriptivos, puede seleccionar el método y el recurso que desea probar, incluir las cabeceras HTTP que desea incluir y crear manualmente el cuerpo de JSON.

Prueba en Modo Avanzado

La página de prueba avanzada permite definir manualmente los parámetros de ruta de acceso, agregar cabeceras y las cargas útiles de solicitud y respuesta.

Para configurar manualmente una prueba de conector:

Haga clic en el enlace de navegación Prueba.
Si ha proporcionado un descriptor, active Probar en Modo Avanzado en On.

La página de prueba avanzada se muestra automáticamente si ha proporcionado una URL de servicio remoto.
Seleccione el método HTTP que desea probar en la lista desplegable.
Especifique los parámetros de la ruta de acceso de recursos en el campo URI Local según sea necesario para realizar pruebas. Por ejemplo:
```
directions/json?origin=los+angeles&destination=seattle
```
El campo se agrega automáticamente con el URI local definido al introducir un nombre de API. A continuación de nuestro ejemplo, el contenido completo del campo sería similar al siguiente:
```
myMapAPI /directions/json?origin=los+angeles&destination=seattle
```
Tenga en cuenta que si ha definido alguna regla, el campo Reglas Aplicadas (debajo del campo Cuerpo) muestra números que corresponden a las reglas aplicables para la operación seleccionada. El campo URL Remota muestra la cadena exacta que se transferirá al servicio para la prueba.
Agregue una o más cabeceras HTTP de solicitud o respuesta según sea necesario.

Estas cabeceras son solo para fines de prueba y no se agregarán a la configuración de la API del conector de REST.
Haga clic en el campo Cuerpo HTTP para crear el cuerpo del mensaje (carga útil) en el editor de código fuente.
Por ejemplo:
```
{
  "status":"ZERO_RESULTS",
  "routes":[ ]
}
```
Mantenga el contenido del cuerpo del mensaje relevante para el propósito del conector, es decir, no realice una depuración del mensaje agregando datos extraños. La inclusión sólo de datos pertinentes en el cuerpo del mensaje facilita la transmisión rápida de la solicitud o respuesta.
Si el servicio al que se está conectando requiere autenticación, abra la sección Autenticación e introduzca sus credenciales de usuario móvil para cada método que pruebe. Si está utilizando credenciales de prueba por defecto, puede omitir este paso.

Con políticas de seguridad basadas en SAML, la identidad del usuario que realiza la llamada se propaga al servicio externo. Para otras políticas de seguridad como la autenticación HTTP básica y el token username, las credenciales utilizadas para la autenticación con el servicio externo se proporcionan en las sustituciones de políticas como claves CSF. En función de la operación que haya definido, es posible que tenga que introducir credenciales específicas para cada operación o que pueda utilizar un juego de credenciales para todos los métodos de autenticación del conector con el servicio.
Haga clic en Guardar como credenciales por defecto de backend móvil actuales para guardar el nombre de usuario y la contraseña que ha proporcionado como valor por defecto.
Si está en la fase de diseño de la creación del conector y solo desea ver si los puntos finales son válidos, haga clic en Credenciales de Prueba del Diseñador de API por Defecto y seleccione un backend móvil con el que esté registrado y su número de versión.
Opcionalmente, puede introducir sus credenciales de usuario móvil (nombre de usuario y contraseña).
Estas credenciales de prueba por defecto son persistentes en todos los métodos que pruebe. Continúan siendo válidos durante la sesión móvil en la nube actual.
Haga clic en Probar Punto Final.

El punto final de prueba cambia a Cancelar Prueba al hacer clic en él. Si desea detener la prueba por cualquier motivo, haga clic en Cancelar Prueba.

Haga clic en Restablecer para borrar los campos y modificar los parámetros de prueba.
Haga clic en Listo cuando haya terminado de probar los puntos finales.