The REST API provides some resources in an additional media type. TheHAL media type application/hal+json describes a format which containslinks and information about other resources. This allows us to embed theprocess definition or assignee of a task directly into the response, which in turnreduces the number of necessary requests to gather all information about asingle task or a list of tasks.

To interact with HAL, you have to set application/hal+json as Accept header. Theresponse of a HAL request always has the following structure:

  1. {
  2. "_links" : {},
  3. "_embedded" : {}
  4. }

The property _links contains relational links that give an easy way to navigate betweenassociated resources. A _links property contains at least a self relational link. Theproperty _embedded includes other linked resources in the representing resource. Eachembedded resource will be structured as a HAL resource.

Example: Resource

Request

GET /task/a-task-id

Request Header:

  1. Accept: application/hal+json

Response

  1. {
  2. "_links" : {
  3. "self": {
  4. "href": "/task/a-task-id"
  5. },
  6. "assignee": {
  7. "href": "/user/demo"
  8. },
  9. ...
  10. },
  11. "_embedded" : {
  12. "group" : [{
  13. "_links" : {
  14. "self" : {
  15. "href" : "/group/management"
  16. }
  17. },
  18. "_embedded" : null,
  19. "id" : "management",
  20. ...
  21. }],
  22. "processDefinition" : [ {...}, {...} ],
  23. ...
  24. },
  25. "id" : "a-task-id",
  26. "name": "Assign Approver",
  27. "assignee": "demo",
  28. ...
  29. }

Example: Collection

Request

GET /task

Request Header:

  1. Accept: application/hal+json

Response

  1. {
  2. "_links" : {
  3. "self": {
  4. "href": "/task"
  5. }
  6. },
  7. "_embedded" : {
  8. "assignee" : [{
  9. "_links" : {
  10. "self" : {
  11. "href" : "/user/demo"
  12. }
  13. },
  14. "_embedded" : null,
  15. id: "demo",
  16. ...
  17. }],
  18. "processDefinition" : [ {...} ],
  19. "task" : [{
  20. "_links" : {
  21. "self": {
  22. "href": "/task/a-task-id"
  23. },
  24. "assignee": {
  25. "href": "/user/demo"
  26. },
  27. ...
  28. },
  29. "_embedded" : {
  30. "variable" : [ {...}, {...} ]
  31. },
  32. "id" : "a-task-id",
  33. "name": "Assign Approver",
  34. "assignee": "demo",
  35. ...
  36. }, {
  37. ...
  38. }]
  39. },
  40. "count" : 2
  41. }

Caching of HAL Relations

During the generation of a HAL response, linked resources are resolved to embedthem. Some of these resolved resources, like process definitions or users, arerarely modified. Also, if user information is stored in an external system (such asLDAP), every request will access this external system which is anunnecessary overhead. To reduce such expensive requests, the REST API can beconfigured to use a cache to temporary store such relations.

This caching can be configured in the web.xml file of the REST API (or the Camunda Web Application incase the REST API is embedded into the Camunda Web Application).

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
  3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4. xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
  5. <!-- ... -->
  6. <listener>
  7. <listener-class>org.camunda.bpm.engine.rest.hal.cache.HalRelationCacheBootstrap</listener-class>
  8. </listener>
  9. <context-param>
  10. <param-name>org.camunda.bpm.engine.rest.hal.cache.config</param-name>
  11. <param-value>
  12. {
  13. "cacheImplementation": "org.camunda.bpm.engine.rest.hal.cache.DefaultHalResourceCache",
  14. "caches": {
  15. "org.camunda.bpm.engine.rest.hal.user.HalUser": {
  16. "capacity": 100,
  17. "secondsToLive": 900
  18. },
  19. "org.camunda.bpm.engine.rest.hal.group.HalGroup": {
  20. "capacity": 100,
  21. "secondsToLive": 900
  22. },
  23. "org.camunda.bpm.engine.rest.hal.processDefinition.HalProcessDefinition": {
  24. "capacity": 100,
  25. "secondsToLive": 600
  26. }
  27. }
  28. }
  29. </param-value>
  30. </context-param>
  31. <!-- ... -->
  32. </web-app>

The HalRelationCacheBootstrap Listener

To bootstrap the caching, the HalRelationCacheBootstrap context listener isused:

  1. <listener>
  2. <listener-class>org.camunda.bpm.engine.rest.hal.cache.HalRelationCacheBootstrap</listener-class>
  3. </listener>

It is configured by the context parameterorg.camunda.bpm.engine.rest.hal.cache.config. The configuration is providedas JSON and consists of two properties:

Property Description
cacheImplementation The class which is used as cache. The class has to implement the org.camunda.bpm.engine.rest.cache.Cache interface. A simple default implementation is provided by the org.camunda.bpm.engine.rest.hal.cache.DefaultHalResourceCache class.
caches A JSON object to specify which HAL relations should be cached. Every HAL relation cache is configured separately and identified by the HalResource class to cache. The possible configuration parameters depend on the cache implementation and have to be available as setters on the implementation class.

DefaultHalResourceCache Configuration Options

The simple default cache implementation DefaultHalResourceCache provides following configurationoptions:

Property Description
capacity The number of maximal cache entries.
secondsToLive The number of seconds a cache entry is valid. If a cache entry is expired, it is removed and resolved again.

List of Resources Which Support Caching

  • Case Definition: org.camunda.bpm.engine.rest.hal.caseDefinition.HalCaseDefinition
  • Group: org.camunda.bpm.engine.rest.hal.group.HalGroup
  • Identity Links (of a Task): org.camunda.bpm.engine.rest.hal.identitylink.HalIdentityLink
  • Process Definition: org.camunda.bpm.engine.rest.hal.processDefinition.HalProcessDefinition
  • Task: org.camunda.bpm.engine.rest.hal.task.HalTask
  • User: org.camunda.bpm.engine.rest.hal.user.HalUser

原文: https://docs.camunda.org/manual/7.9/reference/rest/overview/hal/