You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
HAL is fundamentally a read-only technology. So far, we have allowed the users to perform their own custom write operations by specifying the HTTP method to use and constructing a payload in the right format manually ($post(...), $patch(...), ...). In ecamp3, the payload format, required fields, etc. are not documented at all for users of the API.
There have been some efforts to push the standard further, in order to allow the API to specify more accurately and in a standardized way, how the user can interact with it. The most prominent such evolution of HAL I found is HAL-FORMS. HAL-FORMS goes even further by specifying the crucial form elements in a user interface, with the ultimate goal that the frontend (or API client) of an application should not have to be redeployed when the API changes some fields. HAL-FORMS is adopted by Spring HATEOAS, although being marked as an unstable specification for the time being.
This sounds intriguing, but obviously comes with its own set of problems, at least in the realm of designing and customizing the look of the forms. But we could start by supporting _templates as specified in HAL-FORMS in a similar way to how we support $post etc.:
API response in HAL-FORMS format:
constuser=this.api.get().users({id: 345})// Proposal: Reference templates with a $ sign and the template key// The next line will create a PATCH request to /api/users/345,// with the payload { firstName: 'Jonathan' }awaituser.$edit({firstName: 'Jonathan'})// The next line will create a PATCH request to /api/users/345,// with the payload { firstName: 'Jonathan', lastName: 'Doe-Smith' }// (because firstName is required)user.$edit({lastName: 'Doe-Smith'})
The text was updated successfully, but these errors were encountered:
HAL is fundamentally a read-only technology. So far, we have allowed the users to perform their own custom write operations by specifying the HTTP method to use and constructing a payload in the right format manually (
$post(...)
,$patch(...)
, ...). In ecamp3, the payload format, required fields, etc. are not documented at all for users of the API.There have been some efforts to push the standard further, in order to allow the API to specify more accurately and in a standardized way, how the user can interact with it. The most prominent such evolution of HAL I found is HAL-FORMS. HAL-FORMS goes even further by specifying the crucial form elements in a user interface, with the ultimate goal that the frontend (or API client) of an application should not have to be redeployed when the API changes some fields. HAL-FORMS is adopted by Spring HATEOAS, although being marked as an unstable specification for the time being.
This sounds intriguing, but obviously comes with its own set of problems, at least in the realm of designing and customizing the look of the forms. But we could start by supporting
_templates
as specified in HAL-FORMS in a similar way to how we support$post
etc.:API response in HAL-FORMS format:
Frontend code that uses this data:
The text was updated successfully, but these errors were encountered: