[katello-devel] API v2 - proposed changes in routes

Dmitri Dolguikh dmitri at redhat.com
Tue Mar 5 15:34:45 UTC 2013


>>> So we won't allow labels in the URLs, or labels would be required
>>> to use the deeper nesting?
>>>
>>> GET /organization/ACME/environments      -> {id: 1, label: DEV}
>>> GET /environment/1                       -> {id: 1, label: DEV}
>>> GET /organization/ACME/environments/DEV  -> {id: 1, label: DEV}
>>>
>>> maybe?
>> Heh heh. I suppose labels could be used when the scope is constrained
>> (by the organization in this case). However, I would very much prefer
>>
>> GET /organization/ACME/environments?label=DEV -> {id: 1, label: DEV}
>>
>> As it clearly shows that "DEV" is not an id, and consequently is less
>> permanent, and the resource may or may not be there.
>>
>> -d
> Params would be better. All of the following would return same result:
>
> GET /organization/environments?label=DEV
> GET /organization/environments?name=DEV
> GET /organization/environments?id=1
> GET /organization/environments/1

Sure. The difference between the last two (and the last call should 
really be GET /environments/1 unless environment id is non-unique 
globally) is that:

  - GET /organizations/:id/environments?id=1 (or any other attribute) 
either returns a list of matching resources, or an empty list
  - GET /organizations/:id/environments/1 either returns the resource 
(singular), or a 404

In other words, the difference in semantics between "get" (the resource 
is expected to exist) and "find" (may or may not exist) calls.

-d




More information about the katello-devel mailing list