Feature request: provide HTTP status to the success callback of $resource

[97jaz]

When a $resource request fails, you get the response object passed to the error callback, and you can retrieve that HTTP status from that. When the request succeeds, however, the success callback is given only the payload and the headers.

It's often important to be able to distinguish between different success cases using the HTTP response code. It's not uncommon to have POST requests that either create and return a new resource (HTTP 201) or find and return an existing one that will fill the present need (HTTP 200). Or, say, the difference between a 201 ("your resource was created, and here it is") vs. a 202 ("we'll try to create this resource; check back later").

[IgorMinar]

at the resource level you shouldn't really care about the status code. if anything, you should write an interceptor that will delay the resolution of the promise until the resource is actually created.

in any case the headers object already contain the Status header with the code, so you can get it from there.

I suppose there is no harm in adding the status code into the success callback, but as I said it doesn't sound like the most valid use of the api.

[97jaz]

I'm not looking to be argumentative here, but the claim that you shouldn't care about HTTP status codes at the resource level does not seem credible to me, since it implies that there is only one way for a resource-related request to succeed for any given HTTP verb. And that assumption is not borne out by the HTTP spec. (However, it might be the specific intention of angular.js to provide a simpler concept of "resource" than the one described by HTTP.)

Anyhow, if the status is in the headers object, then that takes care of my problem. I never though to look in the headers object, since the status code isn't actually in the HTTP response headers.

[eddiemonge]

Its only in the header object if the server passes it back as a header property, which most don't do by default, instead passing them back as a status code.

[giggio]

+1. It is important to have the status code.

[eddiemonge]

If the status code was added into the headers that might be acceptable

[giggio]

Changes proposed on #8841 seem simple enough. Why wasn't that integrated?

[glebv]

+1. e.g. I received 204 "No Content", it's successful code, but to understand what kind of code I received I have to check returned data e.g. ! data.hasOwnProperty(id), then ...
it's very inconvenient and is not stable solution.

[dalsh]

@97jaz

the claim that you shouldn't care about HTTP status codes at the resource level does not seem credible to me, since it implies that there is only one way for a resource-related request to succeed for any given HTTP verb

+1 to this

[giggio]

There has been no replies from the angular team on this issue. There is a pending PR to fix this, with accepted CLA, also with no replies.
Is there anyone looking at this?

[gkalpak]

I'm looking at this (now) 😃 Thx for bringing it to our attention.

The feature-set for the eminent 1.5.0 release is currently locked down, but we'll look into getting this into a subsequent release.

[giggio]

@gkalpak Thanks! ;)

[franDayz]

+1 as I deal with same situation as @glebv

[BBlackwo]

+1 I have the same problem. Need to check for a 203. Workaround is here http://stackoverflow.com/a/29435961/2443005

[artisom]

20th june 2016