Prueba de API personalizadas

En Oracle Mobile Hub puede probar sus API personalizadas antes de desplegarlas mediante datos ficticios. También puede probar los conectores REST mediante la página de prueba que admite 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:

  1. Conéctese a Oracle Mobile Hub.
  2. Haga clic en el icono de menú y, a continuación, amplíe Desarrollo y haga clic en Backends.
  3. Seleccione el backend móvil y haga clic en Open.
  4. Haga clic en Configuración en la barra de navegación izquierda.
  5. Copie la URL del punto final de token de SSO situado en URL de entorno.
  6. Pegue la URL copiada en una ventana del explorador web, pero no pulse la tecla Intro.
  7. Copie el ID de cliente ubicado en la sección Consumidor OAuth.
  8. Agregue un parámetro de cadena de consulta a la URL de punto final de token de SSO pegada en el explorador web con el formato ?clientID=[YourClientID] y, a continuación, pulse la tecla Intro. Un ejemplo de la URL sería similar al siguiente:
    https://<YourSSOTokenEndpointURL>?clientID=<yourClientID>
    El explorador le mostrará un token OAuth de conexión única.
  9. En la ventana de backend móvil, haga clic en la página API situada en la navegación izquierda. El explorador cambiará de la página Configuración a la página API.
  10. Haga clic en Seleccionar API.
  11. Haga clic en el nombre de la 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.
  12. Haga clic en el punto final que desea probar.
  13. En la sección Autenticación, seleccione Token de conexión única en el Método de autenticación.
  14. Copie el token OAuth de SSO y péguelo en el campo Elemento de conexión única.
  15. Haga clic en Probar punto final. Si todo es correcto, el servidor responde con el estado 200 y debe ver los datos de JSON en la respuesta.

Prueba de puntos finales de API con datos ficticios

Puede proporcionar datos ficticios en los cuerpos de mensajes de solicitud y respuesta durante la fase de diseño de la configuración de la API. Esto le permite examinar el contexto de cada llamada sin tener que utilizar datos en tiempo real o interactuar con un servicio en tiempo real. Por ejemplo, para probar si el código maneja correctamente un ID no válido, puede agregar un ejemplo en el cuerpo de la solicitud con datos ficticios que contengan un ID 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 FixItFast, los datos ficticios del cuerpo de la respuesta le permiten verificar si se devuelve la información correcta del cliente. A continuación, se muestra un ejemplo de datos ficticios que el desarrollador de servicios podría crear para el cuerpo de respuesta de la operación POST del recurso contact en el ejemplo 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 ficticia le permite llamar a la API desde la aplicación móvil antes de implantar el código personalizado. Esto le 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 cree su primera implantación, la implantación por defecto es la implantación ficticia. Después de crear una implantación real, se convierte en la implantación por defecto para la API.

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

Prueba de la API de conector REST

Una vez definida la API del conector REST y guardada la configuración, deberá verificar que puede enviar una solicitud y recibir los resultados esperados del servicio web. Probar una conexión es un paso opcional, pero puede ahorrarle tiempo identificando y solucionando problemas ahora antes de finalizar la API del conector. La página Test permite probar un punto final a la vez.

Si ha proporcionado un descriptor, tiene dos modos de prueba para elegir:

  • Pruebas estándar

    Si ha proporcionado metadatos de descriptor, se muestra el modo de prueba estándar en el que los cuerpos de solicitud y respuesta se generan a partir de los metadatos descriptivos y se muestran en los separadores Solicitud y Respuesta. Todo lo que tiene que hacer es seleccionar los parámetros con los que probar los métodos GET e incluir las cabeceras HTTP con las que desea 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:

  1. Haga clic en el enlace Probar.
  2. Si ha proporcionado un descriptor, active Prueba en modo avanzado en On.

    La página de prueba avanzada se muestra automáticamente si ha proporcionado una URL de servicio remoto.

  3. Seleccione el método HTTP que desea probar en la lista desplegable.
  4. Especifique cualquier parámetro de ruta de recurso en el campo URI local según sea necesario para realizar pruebas. Por ejemplo:
    directions/json?origin=los+angeles&destination=seattle

    El prefijo del campo se asigna automáticamente al URI local definido al introducir un nombre de API. Siguiendo nuestro ejemplo, el contenido completo del campo tendría este aspecto:

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

    Observe que si ha definido alguna regla, el campo Reglas aplicadas (debajo del campo Cuerpo) muestra números que corresponden a las reglas aplicables a la operación seleccionada. El campo URL remota muestra la cadena exacta que se pasará al servicio para la prueba.

  5. 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.

  6. Haga clic en el campo Cuerpo HTTP para crear el cuerpo del mensaje (la carga útil) en el editor de origen.
    Por ejemplo:
    {
      "status":"ZERO_RESULTS",
      "routes":[ ]
    }

    Mantenga el contenido del cuerpo del mensaje relevante para el propósito del conector, es decir, no bloat el mensaje agregando datos extraños. Incluir solo los datos pertinentes en el cuerpo del mensaje facilita la transmisión rápida de la solicitud o respuesta.

  7. Si el servicio al que se está conectando requiere autenticación, abra la sección Autenticación e introduzca las credenciales de usuario móvil para cada método que pruebe. Si utiliza credenciales de prueba predeterminadas, puede omitir este paso.

    Con las 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 básica HTTP y el token de nombre de usuario, las credenciales utilizadas para autenticarse con el servicio externo se proporcionan en las sustituciones de política como claves CSF. Según la operación que haya definido, puede que tenga que introducir credenciales específicas para cada operación o que pueda utilizar un juego de credenciales para todos los métodos para autenticar el conector con el servicio.

  8. Haga clic en Guardar como credenciales por defecto de backend móvil actuales para guardar el nombre de usuario y la contraseña que proporcione como valor por defecto.
  9. Si está en la fase de diseño de la creación del conector y 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.
    También puede introducir sus credenciales de usuario de Mobile (nombre de usuario y contraseña).

    Estas credenciales de prueba por defecto son persistentes en todos los métodos que pruebe. Permanecen válidos durante la sesión actual de Mobile Hub.

  10. Haga clic en Probar punto final.

    Punto Final de Prueba cambia a Cancelar Prueba al hacer clic en él. Si desea parar la prueba por algún motivo, haga clic en Cancelar prueba.

    Haga clic en Restablecer para borrar los campos y modificar los parámetros de prueba.

  11. Haga clic en Listo cuando haya terminado de probar los puntos finales.