Without judging whether it is a real issue or not, the application is not fully aware of what will come. It knows only that a collection of items will be returned, but the type of these items is not disclosed. Also there is no hint before fetching whether the collection is complete or partial. Hydra Core Vocabulary allows partial collections, but it's unclear how to denote that fact before fetching the collection. This may lead to situation when an application can be "surprised" either by receiving a partial collection forcing it to make additional calls to fill the view (in our case a monthly view of the calendar), or by a complete collection which may contain dozens of items (which are not needed at the time being).
In some situations, it may be useful to separate meta-data from the data, i.e. for the presentation purposes. Without this separation either hypermedia controls could be displayed possibly breaking the visual part of the application, or the client would be forced to do some cleaning. The former is a no go, the latter may prove tricky for pure ReST approach forcing the client to be more of a MVVM.
Again, named graphs would come in handy in this situation, i.e.:
{
"@context": "/api/context.jsonld",
"@graph": [
{
"@id": "meta:data",
"@graph": [
{
"@id": "/api/events",
"operation": [
{
"@type": ["Operation", "schema:CreateAction"],
"title": "Create new event",
"method": "POST",
"expects": "schema:Event"
}
],
"member": [
{
"@id": "/api/events/1"
}
]
}
]
},
{
"@graph": [
{
"@id": "/api/events/1",
"eventName": "Event 1",
"eventDescription": "Some event 1",
"startDate": "2017-04-19",
"endDate": "2017-04-19"
}
]
}
]
}Alternatives would involve some mixed content type payloads or linking.