Description of problem: When you create a VM provisioning request via REST API, you get back an object that contains some data and also a href, but the href has wrong collection specified. Version-Release number of selected component (if applicable): 5.4.1.0 How reproducible: always Steps to Reproduce: I sent these data to the "create" action of the provision_requests: {'miq_custom_attributes': {}, 'version': '1.1', 'additional_values': {'request_id': '1001'}, 'requester': {'owner_first_name': 'John', 'owner_email': 'jdoe', 'user_name': 'admin', 'owner_last_name': 'Doe', 'auto_approve': True}, 'vm_fields': {'vm_name': 'test_rest_prov_ZxxWf2Kof2', 'vm_memory': '2048', 'number_of_cpus': 1, 'provision_type': 'native_clone', 'vlan': 'rhevm'}, 'ems_custom_attributes': {}, 'tags': {'cc': '001', 'network_location': 'Internal'}, 'template_fields': {'guid': u'266937e0-4662-11e5-ba79-fa163eeabf5f'}} These data return as a result of the API call (truncated): {u'status': u'Ok', u'description': u'Provision from [rhel65] to [test_rest_prov_ZxxWf2Kof2]', u'source_type': u'VmOrTemplate', u'request_type': u'template', 'href': 'https://xyz/api/service_requests/16', u'request_state': u'pending', u'message': u'VM Provisioning - Request Created', u'requester_id': 1, u'requester_name': u'Administrator', u'userid': u'admin', u'approval_state': u'pending_approval', u'id': 16, u'created_on': u'2015-08-19T13:26:13Z', u'source_id': 1055, u'updated_on': u'2015-08-19T13:26:15Z', u'type': u'MiqProvisionRequest', u'options': .... } Then I try to get the href (I have a small REST client for the CFME so I do .reload() on the resource and it uses the href/id to load fresh data) Actual results: {"error":{"kind":"not_found","message":"Couldn't find ServiceTemplateProvisionRequest with id=16 [WHERE \"miq_requests\".\"type\" IN ('ServiceTemplateProvisionRequest')]","klass":"ActiveRecord::RecordNotFound"}} Expected results: Data of the provisioning request Additional info: It can definitely be worked around (by not using the href and relying on the id and knowledge of the collection), but it is highly inconvenient to have an invalid URL in the data, or an URL pointing to a completely different resource if the id in href of the another collection is actually a valid URL.
This appears to be a bug in my REST client.