suggestions for non-addressable embedded resources

51 views
Skip to first unread message

jos...@gmail.com

unread,
Feb 14, 2019, 6:15:39 PM2/14/19
to hal-d...@googlegroups.com

Is there any consensus on how to deal with resources that may be contained in an _embedded collection, but aren’t actually addressable on their own with their own self link?

I have resources that to fit the model of HAL make it prudent to include them in a given resource.  Lets say that I have a datamodel where a person has an associated collection of donations.  On most systems implementing the protocol, there is actually an addressable collection of donations where each donation can be gotten with a get to their self link.

I’m applying the protocol to an odd ball system where the donations are returned as part of the actual person representation.  There is no actual donation resource that can be addressed independently.  So instead, I’m including them in the _embedded collection in the person response (rather than a _link to the collection) and taking advantage of HAL conventions so a client can use either approach. They can either look for embedded, and if not follow a link. 

My challenge is that when representing the donations in the embedded collection, the HAL browser expects a self link to work properly and other clients might do the same.

See the example below.  For now I’m just putting ‘#’, which allows the HAL browser to function, but it throws warnings that it can’t normalize the URL.

Is there any consensus on how to deal with this kind of situation?  I could take the approach of HAL subterfuge, by artificially creating a collection and individual addressable resources  where a client enumerating it simply retrieves the person every time, returning only the next donation and throwing the rest of the data away.  That seems wasteful.

{

  "identifiers": [

    "volunteer_hub:247a7f93-1918-4a55-bbd9-ed0914198f37"

  ],

  "given_name": "Michele",

  "family_name": "Ver Ploeg",

  “_embedded”: {

    “donations”: [

      {

       “amount”: 5000000,

       “_links”: {

         “self”: {

           “href”: “WHAT DO I PUT HERE?”

         }

       }

      }

   ]

  }

}

 

 

--- Connection reset by queer
Josh Cohen, EMT  jos...@gmail.com | @joshco | LinkedIn | GitHub  | OSDI | Hit me up to AutoSync your new Salesforce data to VAN and apply Activist Codes nightly

 

Andrej Burger

unread,
Feb 14, 2019, 6:27:35 PM2/14/19
to HAL Discuss
Hi

If it is not "addressable" then it is not a resource (in the REST sense of the word) in my opinion. And thus it should not be in _links and neither in _embedded.
So why not to follow your own suggestion "where the donations are returned as part of the actual person representation" and add it as part of the person representation?
Something like:

{
  "identifiers": [
    "volunteer_hub:247a7f93-1918-4a55-bbd9-ed0914198f37"
  ],
  "given_name": "Michele",
  "family_name": "Ver Ploeg",
  "donations": [
      {
       “amount”: 5000000
      }
   ]
}
(plus self link for the person resource of course)

Regards,
Andrej

Evert Pot

unread,
Feb 14, 2019, 6:27:36 PM2/14/19
to hal-d...@googlegroups.com

Is there a natural key you can use for each individual item?

If not, you might want to consider not using `_embedded` and just create a simple property on the object.

--
You received this message because you are subscribed to the Google Groups "HAL Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hal-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mike Kelly

unread,
Feb 14, 2019, 6:55:15 PM2/14/19
to hal-d...@googlegroups.com
I tend to agree with Andrej. If you have a need for that kind of linked-everything model then it may be worth exploring formats for linked data or if you're really masochistic try full blown RDF :D

--
You received this message because you are subscribed to the Google Groups "HAL Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hal-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Reply all
Reply to author
Forward
0 new messages