I'm working a REST-ful API in which resources which are fairly interrelated. Resources reference each other, and these references may be created or deleted. I'm a little uncertain how to support associating resources together when they reference each other using hyperlinks.

A simple example follows with two resources, A and B.

> 
> 
> ```
> Resource A:
>   name: integer
>   list_b: [list of resource B]
> 
> Resource B:
>   id: integer
>   description: String
> 
> ```
> 
> 

Now, A does not include B in its document, but rather links to it. When using hypermedia, it might look something like this:

> 
> 
> ```
> Resource A:
> {
>     id: 1,
>     list_b: [
>         { id: 1, href: "https://server/api/b/1" },
>         { id: 2, href: "https://server/api/b/2" }
>     ]
> }
> 
> ```
> 
> 

If a user wants to add or delete one of the B references in A's list, how do they do so, taking into account the presence of the hyperlink? I want the user to be able to update the entire A resource in one PUT operation, but nothing in the output indicates which value for B is required. It make sense to me for the user to perform PUT with content like this:

> 
> 
> ```
> Resource A:
> {
>     id: 1,
>     list_b: [
>         { id: 1, href: "https://server/api/b/1" },
>         { id: 2, href: "https://server/api/b/2" },
>         { id: 3 },
>     ]
> }
> 
> ```
> 
> 

and receive the updated resource (in the response) like this:

> 
> 
> ```
> Resource A:
> {
>     id: 1,
>     list_b: [
>         { id: 1, href: "https://server/api/b/1" },
>         { id: 2, href: "https://server/api/b/2" },
>         { id: 3, href: "https://server/api/b/3" }
>     ]
> }
> 
> ```
> 
> 

My concern is that the user won't necessarily know what to include in the resource when updating resource A's `list_b`.

When dealing with hyperlinks from one resource to another, how should creates and updates work? Should clients be allowed to update part of the link (the `id`), or should they be required to update both parts of the link?

**Note:** I know another approach might be exposing a sub-url for resource A. It could expose `list_b` as a resource which is operable via HTTP (allowing clients to use POST, PUT, and DELETE on the list resource itself). But this seems less reasonable when A contains multiple references to other resource types. Each field which references another would potentially require a sub-url, which, if there are 10+ fields, is unwieldy, and requires multiple HTTP requests to update the resource.