Per discussion with Marek Hulan this issue can be solved without modifying the API. The API controllers need to check parameters for has_many relationships and always glue the data sent in the update request with ids that are already assigned to the resource but not readable by the user.

Example:

Having:
  user_a

  org_1 (id: 1) <-- visible to user_a
  org_2 (id: 2) <-- visible to user_a
  org_3 (id: 3)

  domain_1 (id: 1, organization_ids: [1, 3])

Then if an API call is performed as user_a to add org_2 to the domain_1:
  PUT /api/domains/1/ {organization_ids: [1, 2]}

The controller needs to:
  for has_many relationship_parameters.each do |param_name|:
    params[param_name] = params[param_name] + relationships_not_readable_to_user(@domain, param_name)
    # in thies case:     [1, 2] +             [3]
  end

There's another issue around handling parameters for has many relationships in controllers: http://projects.theforeman.org/issues/20888
It's already in Marek's team's iteration so I expect the implementation will start soon. Fix for this bug could be implemented in the layer created for the foreign key constraint error handling.

I like the json-patch format and we will need to add some kind of a patch method in future (probably either json-patch or the jsonapi.org style). On the other hand I feel that adding this would be probably more of an API V3 thing and the update actions should work correctly anyway.

Since PATCH method is not implemented right now, we can argue whether addition of methods is a good reason to update API version or not.

Anyway I agree that this is better than nothing.