La API de Hrider pone a tu disposición diversos Web Services RESTful con los que podrás:
- Crear y modificar Compañías.
- Crear y modificar Administradores.
- Asignar a un administrador permisos para administrar una o más compañías.
- Crear y modificar Departamentos y Puestos.
- Crear y modificar Empleados.
- Asignar las relaciones de supervisor y cliente a un empleado.
- Obtener las Evaluaciones para una compañía.
- Obtener y reenviar Invitaciones para participar en una evaluación.
- Obtener los informes globales para una evaluación.
- Obtener los informes personales para un empleado en una evaluación.
La API está diseñada siguiendo el principio
HATEOS (Hypermedia as the Engine of Application State),
lo que permite una sencilla y consistente forma de utilizar y descubrir la API siguiendo los enlaces
que cada recurso proporciona. En la
sección Java puedes ver cómo sería utilizar la API
desde un lenguaje de programación y la simplicidad y elegancia del código cliente que este principio proporciona.
El siguiente diagrama UML muestra las recursos conceptuales principales con los que la API trabaja y cómo
se relacionan entre ellos:
Premium Account.
Una cuenta PREMIUM puede crear tantas Compañías y Administradores como quiera. Cada Administrador puede
tener permiso para acceder a varias compañías.
Departament / Position.
La organización de una Compañía tiene una estructura de árbol en la que los nodos son Departamentos y
las hojas del árbol son Puestos de trabajo. Un Departamento puede tener uno o ningún departamento
padre, y un Puesto siempre pertenecerá a un único Departamento.
Employee.
Los empleados de una compañía pueden mantener tres tipos de relaciones con otros empleados: supervisor,
cliente y colega. Un empleado puede tener uno o ningún supervisor asignado, así como ninguno o varios
clientes. La relación "colega" queda implícitamente establecida por la relación que mantiene un empleado
con el resto de empleados de su mismo puesto.
Appraisal / Report / FeedbackReport.
Cada una de las evaluaciones creadas con Hrider pueden generar diferentes informes (Reports) según su tipo.
Además, en el caso de evaluaciones de feedback, un evaluado podría tener también su propio informe personal (FeedbackReport).
Invitation.
Los empleados que participan en una evaluación reciben una invitación para participar en ella como
evaluadores. La invitación se envía por email y da acceso a completar las encuestas asignadas al evaluador.
Para empezar debemos obtener una API Key que incluiremos en la cabecera de
cada llamada a la API y que nos autentificará para realizar las diferentes operaciones.
Para hacerlo, el propietario de la cuenta PREMIUM debe acceder a Hrider y
desde
Mi Cuenta acceder al menú
Conexiones >
API Keys y hacer click sobre el botón
Crear Nueva:
Es posible crear tantas API Keys como se quiera y asignar a cada una de ellas diferentes permisos.
Desde la pantalla de edición de la API Key se especifica a qué compañías tiene acceso la API Key,
y desde Permisos si el acceso será de lectura/escritura o solo lectura para cada uno de los recursos:
Para más seguridad, desde IPs permitidas, se puede especificar una lista de IPs (separadas por comas)
para las que únicamente se permitirá el acceso. Cualquier otra llamada desde una IP no incluida
será rechazada.
La API key obtenida se debe incluir en la cabecera "authorization" en cada una de las llamadas realizadas.
Si la API key fuera
oC0aGOzvwLSHJaDQ5kJv2bavrtmjkkYRAnb8BVoN y quisiéramos
obtener los recursos raíz de la API, la llamada desde
Curl podría ser:
curl -i -X GET 'https://dev.hrider.net/api/v1' \
-H 'authorization: bearer oC0aGOzvwLSHJaDQ5kJv2bavrtmjkkYRAnb8BVoN'
Todos los Web Services retornan un objeto JSON expresado en
lenguaje HAL,
que está formado de 3 partes:
- Los atributos del propio objeto
- Un atributo _links que contiene enlaces a otros recursos con los que el objeto está relacionado
- Un atributo _embedded con un resumen de cada uno de los objetos con los que se relaciona.
Aquí tenemos un ejemplo con el JSON de un objeto
Employee cualquiera:
{
"_embedded":{
"company":{
"id":8113,
"name":"ACME SOLUTIONS"
},
"position":{
"id":8348,
"code":"W.DESIGNER",
"name":"WEB DESIGNER"
},
"supervisor":{
"id":9121,
"code":"EMP001",
"email":"[email protected]",
"firstName":"ROGER",
"lastName":"OLIVER",
"photo":"12345"
},
"clients":[]},
"_links":{
"self":{"href":"/v1/companies/8113/employees/12430"},
"company":{"href":"/v1/companies/8113"},
"position":{"href":"/v1/companies/8113/employees/12430/position"},
"supervisor":{"href":"/v1/companies/8113/employees/12430/supervisor"},
"subordinates":{"href":"/v1/companies/8113/employees/12430/subordinates"},
"clients":{"href":"/v1/companies/8113/employees/12430/clients"},
"photo":{"href":"/v1/companies/8113/employees/12430/photo"},
"photoContent":{"href":"/v1/companies/8113/employees/12430/photo?alt=media"}},
"address":"7292 Dictum",
"birthDate":"1976-01-04T23:00Z",
"city":"San Antonio",
"code":"EMP002",
"country":"USA",
"dateCreated":"2020-06-09T09:45Z",
"dateModified":"2017-07-19T07:17Z",
"email":"[email protected]",
"externalId":null,
"firstName":"LAWRENCE",
"gender":"male",
"hireDate":null,
"id":12430,
"lastName":"WISE",
"nationalId":"",
"phone":"1-541-754-3010",
"phone2":"",
"photo":153648986024067666,
"postalCode":"47096",
"province":""
}
-
El atributo _embedded contiene un resumen de cada uno de los objetos con los
que el empleado se relaciona. En este caso incluye un resumen de los datos de su compañía, puesto de trabajo
y supervisor actualmente asignado. El resto de objetos retornados por la API siguen la misma lógica.
-
El atributo _links contiene enlaces a los recursos con los que se relaciona y,
cuando el objeto relacionado puede existir de forma independiente, permite
también establecer o eliminar la relación entre ellos. En el caso de un
empleado, los enlaces son:
Nombre |
Tipo |
Métodos |
Descripción |
self |
Recurso |
GET |
Enlace a si mismo |
company |
Recurso |
GET |
Enlace a la compañía del empleado |
position |
Relación |
GET/PUT/DELETE |
Enlace para establecer el puesto de trabajo del empleado |
supervisor |
Relación |
GET/PUT/DELETE |
Enlace para establecer el supervisor del empleado |
subordinates |
Relación |
GET/PUT/DELETE |
Enlace para establecer los subordinados del empleado |
clients |
Relación |
GET/PUT/DELETE |
Enlace para establecer los clientes del empleado |
photo |
Relación |
GET/POST/DELETE |
Enlace para obtener y subir la foto del empleado |
photoContent |
Relación |
GET |
Enlace para obtener el contenido de la foto del empleado |
En general, el content-type de las peticiones POST para crear y actualizar recursos
es
application/json, para crear y eliminar relaciones entre recursos se utiliza
text/uri-list
con la lista de URIs (una por línea) de los recursos a relacionar. Puedes ver un ejemplo
de como asignar a un administrador dos compañías
aquí.
-
Las fechas se expresan en formato UTC yyyy-MM-ddTHH:mmZ
Para correlacionar los empleados de Hrider con los que tengamos en nuestro propio
sistema el recurso Employee incorpora el atributo
externalId. Si lo
establecemos, podemos luego sustituir el ID del empleado en Hrider con el
valor que le hayamos dado utilizando el prefijo '
external-id=' en cualquiera de
la URIs utilizadas. Por ejemplo, si creamos un empleado con al atributo
externalId 5678 y su ID en Hrider es 1234, estas
dos llamadas para obtener el empleado son equivalentes:
curl -i -X GET 'https://dev.hrider.net/api/v1/companies/12345/employees/1234' \
-H 'authorization: yourAuthAPIKey'
curl -i -X GET 'https://dev.hrider.net/api/v1/companies/12345/employees/external-id=5678' \
-H 'authorization: yourAuthAPIKey'
Esto permite que podamos referenciar al empleado desde nuestro sistema
cuando llamamos a la API sin necesidad de conocer el ID que tiene en Hrider.
La forma más fácil de trabajar con la API es navegar por ella mediante
los enlaces que la propia API retorna. Podemos empezar obteniendo el punto de anclaje principal
que corresponde con la ruta a la versión de la API (
v1):
curl -i -X GET 'https://dev.hrider.net/api/v1' -H 'authorization: bearer yourAPIKey'
La respuesta obtenida es:
{
"_embedded":null,
"_links":{
"self":"v1",
"companies":{"href":"v1/companies"},
"administrators":{"href":"v1/administrators"},
"files":{"href":"v1/files"}
}
}
El objeto contiene los enlaces de primer nivel de la API, y como vemos incluye
en su ruta la misma versión de la API que se utilizó en la petición:
- companies. Enlace para trabajar con compañías.
- administrators. Enlace para trabajar con administradores.
- files. Enlace para trabajar con ficheros.
Algunos servicios pueden contener una colección de objetos demasiado grande para obtenerlos
todos en una única llamada. En estas situaciones, la respuesta se pagina con un número
limitado de resultados y es necesario navegar por el resto de páginas para obtener
los siguientes objetos de la colección. Para navegar por la colección se utilizan los parámetros
page y
pageSize:
En el caso por ejemplo de empleados, la petición:
curl -i -X GET 'https://dev.hrider.net/api/v1/companies/8113/employees?pageSize=2' \
-H 'authorization: yourAPIKey'
Retorna un objeto del tipo colección con únicamente 2 empleados por página del tipo:
{
"total":17,
"_embedded":{
"employees":[ ... ]
},
"_links":{
"self":{"href":"/v1/companies/8113/employees?pageSize=2&page=1"},
"_next":{"href":"/v1/companies/8113/employees?pageSize=2&page=2"},
"_previous":null
}
}
Para navegar a la siguiente página podemos utilizar el link
_next.
Puesto que se trataba de la primera página el valor del link
_previous es null,
en cualquier otro caso podemos utilizarlo para navegar a la página anterior. El atributo
total nos indica el número total de empleados en la colección.
La API retorna errores HTTP junto con un objeto JSON que amplía la información del error con los atributos:
- code. Código de error interno de Hrider
- status. Código de error HTTP
- message. Mensaje de error
- description. Descripción del error
La petición a un objeto que no existe retorna una error HTTP 404 (Not found) de este estilo:
HTTP/2 404
content-type: application/json
content-length: 93
{"code":"E001","status":404,"message":"Not found","description":"Employee '124301' not found"}
La siguiente tabla muestra todos los códigos de error existentes con los códigos de estado HTTP que
pueden contener:
Código |
Descripción |
HTTP Status |
E001 | El objeto solicitado no existe | 404 |
E002 | No autorizado | 403 |
E003 | Petición no válida | 400 |
E004 | El fichero subido supera el máximo de tamaño permitido | 413 |
E005 | Conflicto (por ejemplo, ya existe otro empleado con el mismo código) | 409 |
E006 | 'URL endpoint' no existe | 404 |
E007 | Método no permitido | 405 |
E008 | Petición no aceptable | 406 |
E999 | Error desconocido | 500 |