| 2014-11-14 03:54:22 |
Shaunak Kashyap |
bug |
|
|
added bug |
| 2014-11-14 03:59:58 |
Shaunak Kashyap |
description |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
I think there should be consistency between the request and response representations since they really represent the same resource. My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = flavor resource URL (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make it rather inconvenient for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
I think there should be consistency between the request and response representations since they really represent the same resource. My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = flavor resource URL (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
|
| 2014-11-14 04:00:19 |
Shaunak Kashyap |
description |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make it rather inconvenient for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
I think there should be consistency between the request and response representations since they really represent the same resource. My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = flavor resource URL (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make it rather inconvenient for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = flavor resource URL (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
|
| 2014-11-14 04:00:44 |
Shaunak Kashyap |
description |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make it rather inconvenient for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = flavor resource URL (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make things difficult for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = flavor resource URL (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
|
| 2014-11-14 04:01:14 |
Shaunak Kashyap |
description |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make things difficult for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = flavor resource URL (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make things difficult for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = <flavor resource URL> (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
|
| 2014-11-14 04:01:26 |
Shaunak Kashyap |
description |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make things difficult for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = <flavor resource URL> (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
In the "Create service" API (POST /services), the "flavor_ref" property is used to indicate a flavor ID (e.g. "asia"), not a flavor href (e.g. "http://192.168.59.103:81/v1.0/flavors/asia").
In the "Get service" API (GET /services/{service_id}), the "flavor_ref" property is used to indicate a flavor href, not a flavor ID.
This inconsistency will make things difficult for consumers of the API (such as SDKs and other client code) since such software often uses a common model for serializing request representations and deserializing response representations.
My suggestion would be:
* to use "flavor_id" (instead of "flavor_ref") to indicate flavor IDs in request and response representations of all resources that require/return flavors, and
* to add a new link with rel = "flavor" and href = "<flavor resource URL>" (e.g. "http://192.168.59.103:81/v1.0/flavors/asia") in response representations of all resources that return flavors. |
|
| 2014-11-14 18:09:09 |
Amit Gandhi |
poppy: status |
New |
Incomplete |
|
| 2014-12-05 15:27:47 |
Amit Gandhi |
poppy: importance |
Undecided |
Medium |
|
| 2014-12-05 15:27:54 |
Amit Gandhi |
poppy: assignee |
|
Shaunak Kashyap (ycombinator-o) |
|
| 2014-12-05 15:27:58 |
Amit Gandhi |
poppy: milestone |
|
kilo-2 |
|
| 2014-12-05 15:28:03 |
Amit Gandhi |
poppy: status |
Incomplete |
In Progress |
|
| 2014-12-08 18:21:49 |
OpenStack Infra |
poppy: status |
In Progress |
Fix Committed |
|
| 2015-01-21 15:33:51 |
Amit Gandhi |
poppy: status |
Fix Committed |
Fix Released |
|
