All,
Our API automation has shown that our DELETE API returns different http
status codes depending on what entity is being deleted. Example:
I'm not very familiar with REST API standards but I expected that all
DELETE calls should return a 204… Could we standardize on the status code
and content returned across the board?
Cheers,
Og
The resources listed above that are in Foreman return the object that
was deleted, so I think the 200 response is correct.
The resources that return 204 are correct if they don't include the
object that's returned (empty response body). Those that return 202 are
correct if deletion is asynchronous. (Foreman's org delete is
synchronous, but perhaps Katello's isn't.)
I'd suggest you should either be getting 202s where applicable, and
either all 200s or 204s. I've no opinion on which of the latter is
preferred (whether to return the deleted object). You could file a bug
either against the 200s or the 204s to ask for consistent behaviour.
–
Dominic Cleal
Red Hat Engineering
>> All,
>>
>> Our API automation has shown that our DELETE API returns different http
>> status codes depending on what entity is being deleted. Example:
>>
>> * ActivationKeys => 204
>> * Architecture => 200
>> * ContentView => 202
>> * Domain => 200
>> * Model => 200
>> * OperatingSystem => 200
>> * Organization => 202
>> * Repository => 200
>> * User => 200
>>
>> I'm not very familiar with REST API standards but I expected that all
>> DELETE calls should return a 204… Could we standardize on the status
>> code and content returned across the board?
>
> The resources listed above that are in Foreman return the object that
> was deleted, so I think the 200 response is correct.
>
> The resources that return 204 are correct if they don't include the
> object that's returned (empty response body). Those that return 202 are
> correct if deletion is asynchronous. (Foreman's org delete is
> synchronous, but perhaps Katello's isn't.)
>
> I'd suggest you should either be getting 202s where applicable, and
> either all 200s or 204s.
Should have read: "I'd suggest you should be getting 202s where
applicable, and either all 200s or 204s."
I’ve no opinion on which of the latter is
preferred (whether to return the deleted object). You could file a bug
either against the 200s or the 204s to ask for consistent behaviour.
–
Dominic Cleal
Red Hat Engineering
As I understand the RFC 204 is kind of a catch-all response for all
responses that were completed successfully but have nothing to return. We
do have a resource to return, I can't think of any route that would have no
resource to return.
I'd say fill a redmine issue that standardizes all DELETE response calls to
200 or 202 when async, please.
On 01/08/14 12:15, Dominic Cleal wrote:
On 31/07/14 14:09, Og Maciel wrote:
All,
Our API automation has shown that our DELETE API returns different http
status codes depending on what entity is being deleted. Example:
- ActivationKeys => 204
- Architecture => 200
- ContentView => 202
- Domain => 200
- Model => 200
- OperatingSystem => 200
- Organization => 202
- Repository => 200
- User => 200
I’m not very familiar with REST API standards but I expected that all
DELETE calls should return a 204… Could we standardize on the status
code and content returned across the board?The resources listed above that are in Foreman return the object that
was deleted, so I think the 200 response is correct.The resources that return 204 are correct if they don’t include the
object that’s returned (empty response body). Those that return 202 are
correct if deletion is asynchronous. (Foreman’s org delete is
synchronous, but perhaps Katello’s isn’t.)I’d suggest you should either be getting 202s where applicable, and
either all 200s or 204s.Should have read: “I’d suggest you should be getting 202s where
applicable, and either all 200s or 204s.”I’ve no opinion on which of the latter is
preferred (whether to return the deleted object). You could file a bug
either against the 200s or the 204s to ask for consistent behaviour.–
Dominic Cleal
Red Hat Engineering–
You received this message because you are subscribed to the Google Groups
“Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
–
Daniel Lobato
@elobatoss
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
> As I understand the RFC 204 is kind of a catch-all response for all
> responses that were completed successfully but have nothing to return.
> We do have a resource to return, I can't think of any route that would
> have no resource to return.
> I'd say fill a redmine issue that standardizes all DELETE response calls
> to 200 or 202 when async, please.
>
+1
On Fri, Aug 1, 2014 at 1:17 PM, Dominic Cleal <dcleal+g@redhat.com > mailto:dcleal+g@redhat.com> wrote:
On 01/08/14 12:15, Dominic Cleal wrote: > On 31/07/14 14:09, Og Maciel wrote: >> All, >> >> Our API automation has shown that our DELETE API returns different http >> status codes depending on what entity is being deleted. Example: >> >> * ActivationKeys => 204 >> * Architecture => 200 >> * ContentView => 202 >> * Domain => 200 >> * Model => 200 >> * OperatingSystem => 200 >> * Organization => 202 >> * Repository => 200 >> * User => 200 >> >> I'm not very familiar with REST API standards but I expected that all >> DELETE calls should return a 204... Could we standardize on the status >> code and content returned across the board? > > The resources listed above that are in Foreman return the object that > was deleted, so I think the 200 response is correct. > > The resources that return 204 are correct if they don't include the > object that's returned (empty response body). Those that return 202 are > correct if deletion is asynchronous. (Foreman's org delete is > synchronous, but perhaps Katello's isn't.) > > I'd suggest you should either be getting 202s where applicable, and > either all 200s or 204s. Should have read: "I'd suggest you should be getting 202s where applicable, and either all 200s or 204s." > I've no opinion on which of the latter is > preferred (whether to return the deleted object). You could file a bug > either against the 200s or the 204s to ask for consistent behaviour. -- Dominic Cleal Red Hat Engineering -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscribe@googlegroups.com <mailto:foreman-users%2Bunsubscribe@googlegroups.com>. To post to this group, send email to foreman-users@googlegroups.com <mailto:foreman-users@googlegroups.com>. Visit this group at http://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.–
Daniel Lobato@elobatoss
blog.daniellobato.me http://blog.daniellobato.me
daniellobato.me http://daniellobato.me/GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-users+unsubscribe@googlegroups.com
mailto:foreman-users+unsubscribe@googlegroups.com.
To post to this group, send email to foreman-users@googlegroups.com
mailto:foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.