Description of problem:
Some API responses contain a list of IDs, and others contain a list of hashes. 

For example, a GET request to `/gpgkeys/:id` returns data in this format:

    {u'name': u'foo', u'organization': {u'name': u'ACME', u'label': '...'}}

No organization ID is listed. This means that it is impossible to discover what organization this GPG key belongs to except by issuing a follow-up search to the `/organizations` URL (and hopefully coming up with only one result).

As a second example, a GET request to `/architectures/:id` returns data in this format:

    {
        u'name': u'i386',
        u'operatingsystems': [
            {u'id': 1, u'name': u'rhel65'},
            {u'id': 2, u'name': u'rhel7'},
        ]
    }

This is awkward. In this case, the client can compile a list of associated operating systems by iterating through the returned hashes and fetching through their IDs. It is much easier to deal with a straight list of IDs:

    {u'name': u'i386', u'operatingsystem_ids': [1, 2]}

The API should return either an ID or a list of IDs for all foreign key relationships. Client code can be simple and straightforward if a list of IDs is returned.

Version-Release number of selected component (if applicable):
This has been tested against multiple versions of Satellite. Most recently, this has been tested against a system running Satellite 6.0.4 with the following software installed:

* candlepin-0.9.23-1.el7.noarch
* candlepin-common-1.0.1-1.el7.noarch
* candlepin-guice-3.0-2_redhat_1.el7.noarch
* candlepin-scl-1-5.el7.noarch
* candlepin-scl-quartz-2.1.5-6.el7.noarch
* candlepin-scl-rhino-1.7R3-3.el7.noarch
* candlepin-scl-runtime-1-5.el7.noarch
* candlepin-selinux-0.9.23-1.el7.noarch
* candlepin-tomcat-0.9.23-1.el7.noarch
* elasticsearch-0.90.10-6.el7sat.noarch
* foreman-1.6.0.46-1.el7sat.noarch
* foreman-compute-1.6.0.46-1.el7sat.noarch
* foreman-gce-1.6.0.46-1.el7sat.noarch
* foreman-libvirt-1.6.0.46-1.el7sat.noarch
* foreman-ovirt-1.6.0.46-1.el7sat.noarch
* foreman-postgresql-1.6.0.46-1.el7sat.noarch
* foreman-proxy-1.6.0.30-1.el7sat.noarch
* foreman-selinux-1.6.0.14-1.el7sat.noarch
* foreman-vmware-1.6.0.46-1.el7sat.noarch
* katello-1.5.0-30.el7sat.noarch
* katello-certs-tools-1.5.6-1.el7sat.noarch
* katello-default-ca-1.0-1.noarch
* katello-installer-0.0.64-1.el7sat.noarch
* katello-server-ca-1.0-1.noarch
* openldap-2.4.39-3.el7.x86_64
* pulp-katello-0.3-4.el7sat.noarch
* pulp-nodes-common-2.4.1-0.7.beta.el7sat.noarch
* pulp-nodes-parent-2.4.1-0.7.beta.el7sat.noarch
* pulp-puppet-plugins-2.4.1-0.7.beta.el7sat.noarch
* pulp-puppet-tools-2.4.1-0.7.beta.el7sat.noarch
* pulp-rpm-plugins-2.4.1-0.7.beta.el7sat.noarch
* pulp-selinux-2.4.1-0.7.beta.el7sat.noarch
* pulp-server-2.4.1-0.7.beta.el7sat.noarch
* python-ldap-2.4.6-6.el7.x86_64
* ruby193-rubygem-net-ldap-0.3.1-3.el7sat.noarch
* ruby193-rubygem-runcible-1.1.0-2.el7sat.noarch

How reproducible:
100%, but the exact response of each API URL varies.

Steps to Reproduce:
See the "Description of problem" section of this bug report.

Actual results:
A hash or list of hashes that may or may not contain IDs.

Expected results:
An ID or list of IDs.

Additional info:
n/a