greptilian logo

IRC log for #rest, 2014-11-19

https://trygvis.io/rest-wiki/

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

Time S Nick Message
00:01 shrink0r_ joined #rest
02:40 tr3onlin_ joined #rest
04:38 lemur joined #rest
04:52 tr3online joined #rest
06:15 Andre-B joined #rest
06:22 begriffs joined #rest
07:51 Andre-B joined #rest
08:12 rosstuck joined #rest
08:18 _ollie joined #rest
08:59 talios joined #rest
09:02 tr3online joined #rest
09:04 lemur joined #rest
09:13 shrink0r joined #rest
09:21 Crippy joined #rest
09:51 proteusguy joined #rest
10:03 martinfilliau joined #rest
10:09 marcoslamuria joined #rest
10:09 Left_Turn joined #rest
10:50 shrink0r_ joined #rest
10:52 proteusguy joined #rest
10:58 marcoslamuria joined #rest
11:04 tr3online joined #rest
11:21 marcoslamuria joined #rest
11:23 marcoslamuria joined #rest
11:26 marcoslamuria joined #rest
11:27 Left_Turn joined #rest
11:42 dEPy joined #rest
11:42 interop_madness joined #rest
12:58 interop_katatoni joined #rest
13:04 marcoslamuria joined #rest
13:43 interop_tinpore joined #rest
14:06 interop_madness joined #rest
14:51 blahdeblah_ joined #rest
14:57 blahdeblah joined #rest
15:14 Porpado joined #rest
15:14 Porpado What status code shouls I use for already deleted? I am using 204 for the deletion, but for the same request again what do I use?
15:15 fumanchu_ joined #rest
15:15 trygvis 404 could work, 400 or 410 (the one called 'gone')
15:18 jackalista 404 is consistent with what we are doing also, we consider it a success code if the op was DELETE but failure OW
15:19 tr3online joined #rest
15:21 trygvis jackalista: hm, what do you mean?
15:22 trygvis a delete is supposed to be idempotent so returning 404 is a bit strange
15:22 trygvis but sometimes it is hard to know if it has existed to I guess many systems would return 404
15:26 Porpado Would it ever make sense to just keep returning 204
15:26 trygvis I guess, you're kind of fooling your clients but it might be ok
15:26 _ollie trygvis: why is 404 on a delete strange? and what has that to do with idempotency?
15:27 _ollie if the resource you want to delete doesnt exist, return 404, simple is that
15:29 trygvis how can the client know the difference between "the server says this never existed, I wonder if I'm wrong or the server is wrong" vs "oh, a previous delete must have been completed so I'm ok."
15:30 _ollie exactly… so returning 404 is the right thing :)
15:30 trygvis no, then the client know if it didn't exist ever or if it was deleted by an earlier request
15:30 trygvis so 410 is better than 404
15:30 _ollie you can of course return Gone as well but that reveals that there has been a resource in the first place (which is something you need to keep track of)
15:31 _ollie there's no better/worse… both is fine, depending on what you want to expose to clients
15:31 trygvis yes
15:31 _ollie I was just wondering what idempotency has to do with that…
15:50 tr3online joined #rest
16:08 tr3online joined #rest
16:34 tr3online joined #rest
16:38 fumanchu_ any effect idempotency has on response status codes is a side-effect. idempotency is that the intent of the client was satisfied, regardless of the state of the server when that request was made.
16:39 fumanchu https://tools.ietf.org/html/rfc7231#section-4.2.2
16:48 fumanchu joined #rest
16:49 tr3online joined #rest
16:55 tr3online joined #rest
17:01 jackalista trygvis: if you're doing a delete, say the "1st time" then we return 200 OK on success.  If you try it again, then we might return 404, which for any op other than delete would be considered a failed operationm but for delete, it simply means that your first attemtyppt succeeded so is not a failure code in that context.  and it is idempotent bcause you can try it as many times as you want, the thi
17:04 jackalista trygvis: we have the same semantics for 410, which if you're trying to delete, tells you "it's gone"
17:04 jackalista if you were trying to do something other than delete, however, then this indicates that your op failed as the object of it isn't there
17:04 jackalista we are trying to sort through this stuff now, however, so glad to hear some opinions on it!
17:05 jackalista agree with fumanchu on the idempotency question
17:05 tr3online joined #rest
17:06 jackalista we have created a fully idompotent CRUD i/f, with only save, fetch and delete, all idempotent, so all can be retried, the question we are talking about is whether you return a different staus code on a 2nd or subsequent call for these ops
17:07 jackalista that I'm not as sure of, but I tend to think that it's *nicer* to return 404 or 410 for a delete if the object was already gone so the client knows that a previous op did the delete
17:09 tr3online joined #rest
17:14 jackalista WRT https://tools.ietf.org/html/rfc7231#section-4.2.2
17:15 jackalista recommends using 202 for a successful delete
17:15 jackalista (Accepted)
17:15 jackalista that seems fine
17:16 jackalista or 200, if, like us, you return the entity deleted
17:17 jackalista doesn'ty seem to comment on subsequent requests to delete when one such request on the same resource has already succeeded
17:19 jackalista also, if, like us, you return the entity with 200 OK, then on a subsequent request for deletion you can't return the entity, because it's gone.  so
17:19 jackalista is 204, 404 or 410 better?
17:19 jackalista cuirous what you all think
17:20 _ollie i use 202 only if the action has not been completed yet… 204 if we're sure the entity really is deleted…
17:37 marcoslamuria joined #rest
18:43 tr3online joined #rest
18:50 talios joined #rest
19:05 Andre-B joined #rest
19:15 jackalista thanks ollie, much appreciated [and sorry for the slow response, a little busy]
19:37 gamache jackalista: definitely dont return 410 for a successful DELETE of a resource
19:37 gamache 4xx specifically implies client error
19:37 ramsey 200 or 204 is best
19:38 jackalista is that maarc ramsey?
19:38 ramsey I could possibly see using a 303 to redirect
19:38 ramsey hmm?
19:38 ramsey My first name is not maarc, if that’s what you’re asking.
19:38 jackalista gamache: ah, good point
19:39 jackalista we return 200 on first attempt, if we could delete it
19:39 ramsey 410 would mean that the resource you’re attempting to DELETE is gone
19:39 jackalista some debate on whether to return the same 200 on subsequent attempts (idempotent) or something else
19:39 gamache 410 means "something used to be here, but it's already gone, and it's never coming back"
19:39 jackalista ramsey: prior to your being able to delete it, right?
19:39 saml you can do 404 if client tried to delete not existing resource
19:39 jackalista for 410?
19:39 ramsey well, the request is still idempotent, even if the response changes
19:39 jackalista yes
19:40 jackalista but good point on the 4XX class of errors
19:40 jackalista so 204 is meant to indicazte that there was no content there?
19:40 gamache 410 requires the server to have a concept of previously deleted resources, so it's not a popular choice compared to 404, which presupposes nothing
19:40 gamache 204 means the server was successful, and doesn't want to send you any data
19:40 jackalista yeah, agreed on 404 vs. 410
19:41 gamache traditionally it's used as a response to a successful DELETE, but that is mostly convention
19:41 jackalista I see
19:41 gamache you could just as easy use a 200 OK or 202 Accepted
19:41 jackalista do you mean a REST convention or an HTTP convention, or both?
19:41 gamache both, sure :)
19:41 jackalista ok
19:42 gamache REST is built on HTTP, so it fits both
19:42 jackalista sounbdsa sorta like 204 is the best reponse when the object is already gone
19:42 ramsey well, REST doesn’t define any concept of response status codes or interfaces, so this is primarily about HTTP conventions. :-)
19:42 jackalista especially considering that if it wasn't gone, we'd hand it to you as the reponse
19:42 gamache here's the thing though
19:42 jackalista *response
19:42 gamache DELETE should be idempotent in its effect, not in its response
19:43 gamache so 204 the first time and then 404 the next times is fine
19:43 jackalista ramsey: we want to standardize our *interprestation* of the response codes for services
19:43 gamache because system state has not changed since the first time
19:43 jackalista *interpretation
19:44 saml DELETE  gave 204 and then 500 and then 301 and then 204 ... etc
19:44 ramsey saml: huh?
19:44 jackalista gamache: yes, on the effect
19:44 saml since it's never 4xx, never client's fault
19:44 gamache haha, saml is making a funny
19:44 saml so is it idempotent?
19:44 ramsey state of server has not changed
19:45 ramsey so, yes
19:45 gamache yeah I would call that idempotent.  idempotent and brain-damaged :)
19:45 jackalista lol
19:46 gamache but it's right in the HTTP RFC that idempotent methods don't require the same response, only the same ending state
19:46 gamache http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.2
19:47 jackalista so, just out of curiosity, we return the deleted object in our delete call, and return 200 OK for that, when the delete succeeds.
19:47 ramsey side-effects all occur on the server
19:47 ramsey jackalista: I think that’s fine
19:47 gamache jackalista: yeah that looks fine
19:47 jackalista we have minor debate about what to do if a second (idempotent) delete call is made, and since this call can't return the object deleted, since it's no longer avialble, sounds like 204 is the best reponse
19:48 jackalista pardon my horrendous types, sheesh
19:48 jackalista typos
19:48 ramsey or 404
19:48 gamache jackalista: but that forces your server to keep track of what used to exist but no longer does
19:48 gamache jackalista: if you just return 404 after it's been deleted, you don't have to keep track of that
19:48 gamache that'll be a big advantage if you scale
19:48 jackalista thx ramsey, gamache :)
19:48 gamache np!
19:50 tr3online joined #rest
19:50 jackalista gamache: we do'nt keep track of anything, but if the objhect you're trying to delete isn't there, we want to know what response code to return.  There is some sense that it could be a 404, since the object isn't there, you could consider it a client error
19:51 gamache jackalista: if you aren't keeping track of things that used to be there, what do you return when someone DELETEs a resource that never existed?
19:51 jackalista or you could return 204, which doesn't signal an error, but give s slightly unclear indication that there's nothing there
19:51 gamache 2xx seems funky in that case.
19:51 gamache jackalista: 204 doesn't mean "there's nothing there"
19:51 jackalista same thing as when it's the 2nd delete
19:51 jackalista that's what the argument is about :)
19:51 gamache 204 means "this response does not have a body"
19:51 jackalista it means that the server didn't return any content
19:51 jackalista and there was no error
19:51 gamache a 200 OK with no body is semantically the same thing
19:52 jackalista right
19:52 jackalista agreed
19:52 Andre-B joined #rest
19:52 jackalista but since we do return the object when it was there prior to your delete call, it would be nice to return a code consistentwith that
19:52 ramsey 2xx means “success,” so returning that on a DELETE request would indicate to the client that the resource requested was, in fact, deleted.
19:52 tr3online joined #rest
19:53 ramsey but it wasn’t there anymore, so that wouldn’t make sense
19:53 jackalista so a subsequent call to delete is best to indicate to client, "hey, that thing you want to delete doesn 't exist!"?
19:53 ramsey right
19:53 gamache 404 seems to make the most sense to me
19:53 gamache do what you like
19:53 gamache :)
19:53 jackalista lol
19:54 jackalista ok,I'm cool with 404 in that case
19:54 jackalista in a strict sense, the 2nd call to delete was a client error, and this indicates that there's no object there
19:54 jackalista clinet will know if they got a clear object from the first delete with 200 OK
20:03 maxgsc joined #rest
20:05 shrink0r joined #rest
20:19 talios joined #rest
20:42 fumanchu "REST is built on HTTP..." sigh. Fielding is rolling over in his grave.
20:42 gamache who gives a shit
20:44 Andre-B joined #rest
20:45 gamache it is 2014 and perhaps every REST implementation uses HTTP
20:45 gamache whatever "REST implementation" even means.
20:45 trygvis CoAP is on the rise!
20:45 trygvis but it is http-compatible enough to say that rest is built on http :)
20:49 fumanchu you can't spell "history" without "s", "h", "i", "t"
20:49 trygvis haha
20:49 gamache serves us right for hanging out in an IRC channel dedicated to a chapter outta some random dude's PhD thesis
20:51 gamache personally I could give a shit about REST.  I use hypermedia and JSON and HTTP and get my work done just fine :)
21:11 marcoslamuria joined #rest
21:40 Andre-B joined #rest
22:25 tr3online joined #rest
22:30 tr3online joined #rest
22:37 Andre-B joined #rest

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

https://trygvis.io/rest-wiki/