Especificaciones de los intercambios REST
Los servicios web utilizan los principios comunes de las API REST. El formato de intercambio utilizado es JSON.
Autenticación
La API REST utiliza la autenticación básica: Para más información, dirigase aqui: Fase de autentificación. Para recordar su clave, consulte el siguiente artículo: Requisito previo.
Parámetros de la solicitud
La aplicación espera un JSON válido como entrada de solicitud. Por ejemplo, Charge/SDKTest interpretará Type/String object como valor de entrada.
La llamada debe realizarse de la siguiente forma:
{ "value": "my testing value" }
/** * Initialize the SDK * Please update your keys in keys.php */ $client = new Lyra\Client(); /** * I send test data */ $store = array("value" => "my testing value"); $response = $client->post("V4/Charge/SDKTest", $store);
Parámetros de la respuesta
Cuando el Servicio Web responde, devuelve:
{ "webService":"Charge/SDKTest", "version":"V4", "applicationVersion":"4.1.2", "status":"SUCCESS", "answer": { "value":"my testing value", "_type":"V4/Type/String" }, "ticket":null, "serverDate":"2018-10-02T16:13:57+00:00", "applicationProvider":"COIN", "metadata":null, "_type":"V4/WebService/Response" }
El objeto solicitado se devuelve en un objeto de respuesta genérica en donde:
parámetros | TIPO | Descripción |
---|---|---|
webService | Cadena | Servicio web llamado, formato: [namespace]/[web_service_name] |
version | Cadena | versión de la API |
status | Cadena | estado de la respuesta: SUCCESS o ERROR |
answer | Objeto | respuesta comercial |
ticket | Cadena | número de ticket que transmitir al soporte (no implementado) |
applicationProvider | Cadena | plataforma que entrega el servicio |
applicationVersion | Cadena | versión de la aplicación |
metadata | Objeto | reservado para uso interno |
serverDateTime | Cadena | fecha del servidor que ha respondido, en UTC |
_type | Cadena | tipo del objeto. Comienza siempre por el número de versión |
Manejo de errores
En caso de error del Servicio Web:
{ "amount": -1 }
La respuesta es:
{ "webService": "Charge/CreatePayment", "version": "V4", "applicationVersion": "4.5.1", "status": "ERROR", "answer": { "errorCode": "INT_902", "errorMessage": "web-service input data validation error", "detailedErrorCode": null, "detailedErrorMessage": "can't decode JSON data : {\n \"amount\": -1,\n}", "ticket": "null", "_type": "V4/WebService/WebServiceError" }, "ticket": null, "serverDate": "2018-12-10T19:27:32+00:00", "applicationProvider": "", "metadata": null, "_type": "V4/WebService/Response" }
El Servicio Web ha fallado y devuelve un objeto WebService/WebServiceError :
CARACTERÍSTICAS | TIPO | Descripción |
---|---|---|
errorCode | Cadena | Código de error (en el formato [PREFIJO]_[CÓDIGO]) |
errorMessage | Cadena | Mensaje de error |
detailedErrorCode | Cadena | Código de error detallado (o nulo) |
detailedErrorMessage | Cadena | Mensaje detallado (o nulo) |
Para más detalles sobre errores, vaya a: Códigos de error.
¿Por qué la API no es 100% REST?
Buscamos desarrollar una API tan simple como sea posible para evitar los errores comunes:
Solo utilizamos el método POST.
Así nos evitamos las preguntas habituales sobre qué método utilizar: SIEMPRE POST.
Todos los parámetros de búsqueda se envían como un objeto JSON :
- Solo hay una forma de enviar los parámetros (no se agrega nada a la URL).
- Los registros son más simples.
- La API responde siempre HTTP 200
Por esta razón, no es necesario gestionar varios códigos de estado HTTP, la respuesta es siempre 200. El estado del Servicio Web se puede consultar en el interior del objeto JSON.
Fecha y hora
El objeto datetime está en formato ISO 8601.
El servicio web acepta todos los husos horarios como:
- 2015-11-19T16:56:57+00:00
- 2015-11-19T16:56:57+01:00
- 2015-11-19T16:56:57+Z
El servidor devuelve siempre el objeto datetime en hora UTC (GMT+00) :
- 2015-11-19T16:56:57+00:00
El servidor nunca devuelve 2015-11-19T16:56:57+Z
Valores nulos
Los valores nulos no obligatorios se eliminan automáticamente de la respuesta. Es decir, una propiedad nula se incluye en la respuesta si y solo si la clave es obligatoria y nulo es un valor aceptable.