| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-13 | |||
| 14:45:05 | elmiko | and i imagine we would definitely point that person in the right direction | |
| 14:45:15 | cdent | "hey caller, it looks like you're using nova, you might want to talk to ..." | |
| 14:45:25 | elmiko | anyways, it was just a thought. i don't think it's a concern, but if i pushed to make a critique. | |
| 14:45:32 | elmiko | yeah | |
| 14:45:52 | elmiko | i still don't have an objection, i was just trying to go deeper with due diligence =) | |
| 14:51:15 | edleafe | elmiko: Sorry, was afk | |
| 14:51:47 | edleafe | I can see what you mean, but I kinda think that's a good thing. The more interest in the SIG, the better | |
| 14:52:16 | elmiko | i like that attitude =) | |
| 14:52:17 | edleafe | Like cdent said, we may not have the answers, but we might help point people to better resources | |
| 14:52:25 | elmiko | agreed | |
| 14:56:41 | elmiko | thanks for indulging me ;) | |
| 15:11:57 | cdent | elmiko: speaking of indulgences, how did your aqua vit settle in at home. did it even make it home? | |
| 15:12:31 | elmiko | haha, yes! it made it home | |
| 15:12:35 | elmiko | it's been a big hit =) | |
| 15:13:02 | elmiko | people are becoming scared at the volume of clear liquors i am pushing on them when they visit XD | |
| 15:13:35 | cdent | here, try this mysterious thing! | |
| 15:23:49 | elmiko | basically | |
| 15:24:31 | elmiko | at least with the eau de vie they kinda get it, but when i start digging out stuff slike slivovice and awamori things get /interesting/ =D | |
| 15:25:24 | elmiko | the liquor cabinet is starting to look a little nuts though, like "does this guy have a problem?" haha | |
| 16:00:17 | edleafe | API-SIG Office Hour has begun | |
| 16:00:43 | edleafe | Get your feet off the table!! Were you raised in a barn? | |
| 16:01:38 | elmiko | sadly no, just a normal house | |
| 16:03:10 | edleafe | dtantsur: around? Wanted to get your feedback on http://paste.openstack.org/show/737157/ | |
| 16:03:32 | edleafe | It's the little blurb for the OpenStack Foundation Annual Report about our SIG | |
| 16:03:58 | dtantsur | edleafe: sounds perfect to me | |
| 16:04:16 | edleafe | kewl | |
| 16:04:51 | dtantsur | also JFYI I'm off starting tomorrow, back in Jan | |
| 16:04:51 | edleafe | The only other issue I had was whether to freeze https://review.openstack.org/#/c/616610/ | |
| 16:05:01 | edleafe | lucky you! | |
| 16:05:19 | edleafe | I'm around all next week, then back 2nd week of Jan | |
| 16:05:58 | elmiko | i'll be around next week as well | |
| 16:07:25 | edleafe | dtantsur: so you would prefer to interpret DELETE as "find this resource, and then delete it" | |
| 16:07:48 | edleafe | instead of "make sure this resource doesn't exist" | |
| 16:07:56 | dtantsur | edleafe: "delete this resource", yes | |
| 16:09:01 | dtantsur | I think if somebody is actually going to follow this guideline, it's going to be confusing for users | |
| 16:09:15 | dtantsur | e.g. `rm /foo` actually errors out | |
| 16:10:48 | edleafe | So consider this scenario: resource `foo` exists. Two users call DELETE /rsrc/foo. One should get 204, and the other 404? | |
| 16:13:04 | dtantsur | right | |
| 16:14:36 | elmiko | i think the only weird part to me is how long should that behavior persist after the delete? | |
| 16:14:54 | kmalloc | Shrews: now that my massive headache of doom has passed, i should be able to look at dogpile and the other issues outstanding | |
| 16:15:02 | elmiko | like, if i delete a resources ages ago, when should the server respond with a 404? | |
| 16:15:04 | kmalloc | Shrews, mordred: ^ thanks for bearing with me yesterday. | |
| 16:15:34 | elmiko | or should it ever? which implies keeping track of delete resources for the purposes of delete responses | |
| 16:15:54 | edleafe | RFC 7231 says that DELETE is idempotent: https://tools.ietf.org/html/rfc7231#section-8.1.3 | |
| 16:15:56 | dtantsur | tracking deleting resources is quite a change to many database models | |
| 16:16:41 | dtantsur | edleafe: that's one of the reasons HTTP is not a great match for API.. | |
| 16:17:03 | kmalloc | edleafe: oh good to know. | |
| 16:17:15 | kmalloc | edleafe: also... damn that means keystone has messed up a bunch. | |
| 16:18:07 | elmiko | edleafe: such a weird knot this is, it should be idempotent, but does that mean it should always return some 2XX for a previously deleted resource? | |
| 16:18:33 | elmiko | i mean, i know that's what we are proposing i'm just exploring the idea a little more | |
| 16:18:40 | dtantsur | yeah, this is a weird point | |
| 16:19:11 | elmiko | definitely | |
| 16:19:22 | edleafe | The impetus for adding this guideline is that it is assumed that an API has one implementation, but many, many consumers. Attempting to delete a resource that doesn't exist requires an exception handler. If you can return a 404 from the API, every single consumer of that API has to build code to handle that | |
| 16:19:36 | edleafe | elmiko: why not? | |
| 16:19:54 | edleafe | "I don't want resource foo to exist" "OK, it doesn't exist" | |
| 16:20:06 | dtantsur | "In effect, this method is similar to the rm command | |
| 16:20:09 | dtantsur | in UNIX: it expresses a deletion operation on the URI mapping of the | |
| 16:20:10 | dtantsur | origin server rather than an expectation that the previously | |
| 16:20:12 | dtantsur | associated information be deleted. | |
| 16:20:21 | dtantsur | I don't know how to interpret it.. | |
| 16:20:25 | elmiko | edleafe: it just makes me wonder what the impl starts to look like, for example do i need to keep a database table of delete resources to properly respond to all future delete requests? | |
| 16:20:40 | dtantsur | edleafe: the "very single customer" is simply incorrect | |
| 16:20:40 | edleafe | elmiko: why? | |
| 16:20:53 | elmiko | if i delete some resource /foo/bar | |
| 16:21:09 | dtantsur | I personally very rarely catch 404 from deletions because I *want* to know that something went south | |
| 16:21:15 | elmiko | then later a request comes in to DELETE /foo/bar, then i need to respond 2XX if it has been deleted. is that accurate? | |
| 16:22:25 | edleafe | elmiko: if you call DELETE /foo/bar, and `foo` is a valid resouce class, you return 204 whether or not you had to delete resource `bar` or not. You don't need to confirm that `bar` ever existed. | |
| 16:23:09 | edleafe | dtantsur: that's very different than "I want this resource gone" | |
| 16:23:31 | edleafe | dtantsur: if you care that it's there and getting deleted, do a GET/HEAD on it first | |
| 16:23:33 | dtantsur | well, "I want this resource gone" is not the semantic I use, so no wonder :) | |
| 16:23:38 | elmiko | edleafe: what if "bar" never existed as a foo? | |
| 16:23:46 | elmiko | shouldn't that be a 404? | |
| 16:23:50 | edleafe | elmiko: No | |
| 16:23:58 | dtantsur | edleafe: so instead of handling 404 by some consumers, some other consumers have to make 2 requests? | |
| 16:24:03 | elmiko | ah, i misunderstood you then | |
| 16:24:13 | edleafe | if you interpret delete as "I don't want resource bar to exist" | |
| 16:24:28 | dtantsur | then we should allow 'DELETE /some/nonsense' :) | |
| 16:24:46 | dtantsur | half-kidding, but the same logic can be applied to invalid URLs | |
| 16:24:47 | edleafe | If you care about the existence of a resource, you call GET or HEAD | |
| 16:24:59 | kmalloc | it's fine to say DELETE X and if the path is unrouted, get a 404 | |
| 16:25:08 | kmalloc | afaict. | |
| 16:25:14 | kmalloc | no | |
| 16:25:14 | kmalloc | acutally | |
| 16:25:15 | dtantsur | kmalloc: why? I want it to be gone, and it's gone | |
| 16:25:18 | edleafe | dtantsur: cdent clarified that. Just what kmalloc said | |
| 16:25:20 | kmalloc | that would be a method not allowed | |
| 16:25:31 | dtantsur | edleafe: not for me | |
| 16:25:31 | kmalloc | sorry, wrong error | |
| 16:25:36 | kmalloc | not 404, 40.. 405? | |
| 16:25:42 | elmiko | kmalloc: if it's possible that the resource _could_ have existed, then it should 404. if i understand edleafe's point | |
| 16:25:48 | elmiko | er should not! | |
| 16:25:49 | elmiko | sorry | |
| 16:25:53 | kmalloc | elmiko: right | |
| 16:26:13 | kmalloc | elmiko: it should be .. 200/204/2XX (not 201) | |
| 16:26:18 | elmiko | right | |
| 16:26:28 | edleafe | Generally 204 is returned from DELETE | |
| 16:26:41 | kmalloc | if delete is not allowed, e.g. the whole path is unrouted in an api | |
| 16:26:44 | edleafe | There is no response body | |
| 16:26:54 | kmalloc | XXXX/<resource> -> where XXXX is not a thing at all | |
| 16:26:56 | kmalloc | that should be 405 | |