| *** annegentle has joined #openstack-api | 00:44 | |
| *** annegentle has quit IRC | 00:49 | |
| *** Apoorva_ has quit IRC | 01:17 | |
| *** salv-orlando has joined #openstack-api | 01:43 | |
| *** salv-orlando has quit IRC | 01:52 | |
| *** nightanne has joined #openstack-api | 02:34 | |
| *** salv-orlando has joined #openstack-api | 02:36 | |
| *** salv-orlando has quit IRC | 03:10 | |
| *** nightanne has quit IRC | 03:35 | |
| *** nightanne has joined #openstack-api | 03:36 | |
| *** nightanne has quit IRC | 04:09 | |
| *** salv-orlando has joined #openstack-api | 04:11 | |
| *** salv-orlando has quit IRC | 04:20 | |
| *** salv-orlando has joined #openstack-api | 05:24 | |
| *** salv-orlando has quit IRC | 05:34 | |
| *** ig0r__ has joined #openstack-api | 05:52 | |
| *** ig0r_ has quit IRC | 05:55 | |
| *** subscope has quit IRC | 06:25 | |
| *** salv-orlando has joined #openstack-api | 06:37 | |
| *** subscope has joined #openstack-api | 06:38 | |
| *** salv-orlando has quit IRC | 06:40 | |
| *** salv-orlando has joined #openstack-api | 07:09 | |
| *** sigmavirus24_awa has quit IRC | 07:27 | |
| *** dolphm has quit IRC | 07:30 | |
| *** stevelle has quit IRC | 07:32 | |
| *** alex_klimov has joined #openstack-api | 07:39 | |
| *** salv-orlando has quit IRC | 07:39 | |
| *** fzdarsky has joined #openstack-api | 08:06 | |
| *** lucasagomes has joined #openstack-api | 08:16 | |
| *** salv-orlando has joined #openstack-api | 08:20 | |
| *** cdent has joined #openstack-api | 08:30 | |
| *** e0ne has joined #openstack-api | 09:51 | |
| *** alex_klimov has quit IRC | 10:27 | |
| *** alex_klimov has joined #openstack-api | 10:37 | |
| *** e0ne is now known as e0ne_ | 10:49 | |
| *** dolphm has joined #openstack-api | 10:53 | |
| *** e0ne_ is now known as e0ne | 11:01 | |
| *** lucasagomes is now known as lucas-hungry | 11:15 | |
| *** e0ne is now known as e0ne_ | 11:35 | |
| *** nightanne has joined #openstack-api | 12:08 | |
| *** nightanne is now known as morninganne | 12:11 | |
| *** ig0r__ has quit IRC | 12:17 | |
| *** e0ne_ is now known as e0ne | 12:21 | |
| *** terrylhowe has joined #openstack-api | 12:23 | |
| *** ig0r_ has joined #openstack-api | 12:23 | |
| *** lucas-hungry is now known as lucasagomes | 12:34 | |
| *** e0ne is now known as e0ne_ | 12:46 | |
| *** e0ne_ is now known as e0ne | 12:47 | |
| *** morninganne has quit IRC | 13:31 | |
| *** woodster_ has joined #openstack-api | 13:36 | |
| *** morninganne has joined #openstack-api | 13:42 | |
| *** morninganne has quit IRC | 13:43 | |
| *** morninganne has joined #openstack-api | 14:01 | |
| *** sigmavirus24_awa has joined #openstack-api | 14:04 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:04 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 14:05 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:05 | |
| *** morninganne has quit IRC | 14:11 | |
| *** morninganne has joined #openstack-api | 14:39 | |
| *** fifieldt has quit IRC | 14:49 | |
| *** morninganne has quit IRC | 14:50 | |
| *** morninganne has joined #openstack-api | 14:51 | |
| *** alex_xu has quit IRC | 15:08 | |
| *** alex_xu has joined #openstack-api | 15:10 | |
| *** notmars has joined #openstack-api | 15:15 | |
| *** ig0r__ has joined #openstack-api | 15:19 | |
| *** ig0r_ has quit IRC | 15:22 | |
| *** e0ne is now known as e0ne_ | 15:28 | |
| *** e0ne_ is now known as e0ne | 15:29 | |
| *** Apoorva_ has joined #openstack-api | 15:56 | |
| *** notmars has quit IRC | 16:01 | |
| *** stevelle has joined #openstack-api | 16:04 | |
| *** e0ne has quit IRC | 16:11 | |
| *** cdent has quit IRC | 16:12 | |
| *** alex_klimov has quit IRC | 16:14 | |
| *** salv-orlando has quit IRC | 16:44 | |
| *** notmars has joined #openstack-api | 16:48 | |
| *** bitblt has joined #openstack-api | 17:01 | |
| *** fzdarsky has quit IRC | 17:03 | |
| *** lucasagomes is now known as lucas-beer | 17:27 | |
| *** e0ne has joined #openstack-api | 17:28 | |
| *** salv-orlando has joined #openstack-api | 17:46 | |
| *** salv-orlando has quit IRC | 17:50 | |
| *** e0ne has quit IRC | 17:52 | |
| *** e0ne has joined #openstack-api | 17:54 | |
| *** e0ne has quit IRC | 17:58 | |
| *** morninganne has quit IRC | 18:10 | |
| *** terrylhowe has quit IRC | 18:55 | |
| *** terrylhowe has joined #openstack-api | 18:57 | |
| *** morninganne has joined #openstack-api | 19:03 | |
| *** etoews has quit IRC | 19:07 | |
| *** morninganne is now known as annegentle | 19:12 | |
| *** ig0r__ has quit IRC | 19:19 | |
| *** ig0r_ has joined #openstack-api | 19:20 | |
| *** salv-orlando has joined #openstack-api | 20:04 | |
| *** bitblt has quit IRC | 20:14 | |
| *** salv-orl_ has joined #openstack-api | 20:15 | |
| *** salv-orlando has quit IRC | 20:18 | |
| *** salv-orl_ has quit IRC | 20:22 | |
| *** salv-orlando has joined #openstack-api | 20:30 | |
| *** annegentle has quit IRC | 20:39 | |
| *** ig0r_ has quit IRC | 21:10 | |
| *** salv-orlando has quit IRC | 21:11 | |
| *** annegentle has joined #openstack-api | 21:18 | |
| *** annegentle has quit IRC | 21:19 | |
| *** annegentle has joined #openstack-api | 21:20 | |
| *** salv-orlando has joined #openstack-api | 21:21 | |
| *** notmars has quit IRC | 21:39 | |
| elmiko | miguelgrinberg: you around? | 21:50 |
|---|---|---|
| miguelgrinberg | elmiko: yup | 21:51 |
| elmiko | do you have an opinion on using query parameters in POST and PUT? | 21:51 |
| miguelgrinberg | normally you'd want all the info in the body of the request, what's a use case for having query string args? | 21:52 |
| elmiko | i was commenting on a review about a copy style request for a resource | 21:52 |
| miguelgrinberg | I don't think it goes against REST, if that's the question, but it is unusual | 21:53 |
| elmiko | and one suggestion was to use a special parameter in the json body for the request | 21:53 |
| elmiko | another suggestion was to create a special copy endpoint, resource/<id>/copy | 21:53 |
| elmiko | and i suggested as an alternative, resource/<id>?copy_from=<another id> | 21:54 |
| elmiko | have you come across anything like this? | 21:54 |
| miguelgrinberg | so you are creating a new resource, using an existing one as sort of a template | 21:54 |
| elmiko | yes | 21:54 |
| elmiko | if you have time, i'm sure they'd love any thoughts you have on https://review.openstack.org/#/c/127823/ | 21:54 |
| miguelgrinberg | any reason why you can't read the source resource and then create a new one with the same data? | 21:55 |
| elmiko | not that i'm aware of, i think the barbican folks were trying to create a copy endpoint. i'm not sure about the whole use case though | 21:57 |
| elmiko | maybe they don't want to round trip the unencrypted payload | 21:57 |
| elmiko | that's just speculation though | 21:57 |
| miguelgrinberg | yeah, I guess I would not be able to argue about that if we are talking sensitive info | 21:58 |
| miguelgrinberg | in a normal case you would just GET the source and then POST it to get a copy | 21:58 |
| elmiko | right, that makes sense | 21:58 |
| elmiko | i'll add a comment in the review | 21:58 |
| elmiko | thanks! | 21:59 |
| miguelgrinberg | elmiko: they say it in the spec: "Currently, this is done by | 22:00 |
| miguelgrinberg | retrieving and re-storing the secret. This would be better done in the | 22:00 |
| miguelgrinberg | barbican server directly, so that secrets need not be manipulated outside | 22:00 |
| miguelgrinberg | the barbican server." | 22:00 |
| elmiko | ah, there we go | 22:00 |
| miguelgrinberg | why do we always have to deal with hard problems? | 22:00 |
| elmiko | lol | 22:01 |
| miguelgrinberg | maybe a query argument can work for this, I think it is better than the body, since you are not sending resource data | 22:01 |
| miguelgrinberg | Oh, I know. How about sending a POST request to the resource URL, the one you want to copy? | 22:02 |
| elmiko | i think that's what they are suggesting, POST resource/<id to copy> | 22:03 |
| miguelgrinberg | that's not what the spec says, they are using the same collection URL, and passing a copy_ref value in the body | 22:04 |
| elmiko | heh, i just hit service unavailable | 22:04 |
| elmiko | maintenance | 22:04 |
| miguelgrinberg | yeah, I'll ask them about that idea | 22:05 |
| stevelle | post to the collection with a query argument? | 22:05 |
| stevelle | just catching up here | 22:05 |
| miguelgrinberg | stevelle: we have 3 options | 22:05 |
| elmiko | stevelle: that's what i had suggested | 22:05 |
| miguelgrinberg | #1 post to collection URL with query_ref argument to source resource | 22:05 |
| miguelgrinberg | #2 post to collection URL with copy_ref argument in body (this is what the spec says now) | 22:06 |
| miguelgrinberg | #3 post to source resource URL (my proposal) | 22:06 |
| elmiko | they also had a fourth idea in the spec, post to a resource/<id>/copy endpoint | 22:07 |
| miguelgrinberg | okay, so #4 is to have a dedicated endpoint for copying | 22:07 |
| elmiko | yea | 22:07 |
| stevelle | I would say that 2 is not as clean unless the clone has a property that identifies where it was cloned from. | 22:07 |
| miguelgrinberg | so copy_ref is the URL of the resource you want to copy | 22:08 |
| stevelle | something not right about posting what looks like a property for a new resource and not having that property in the resulting resource | 22:08 |
| miguelgrinberg | yes, agreed | 22:08 |
| elmiko | agreed | 22:09 |
| stevelle | for #3 are you suggesting an querystring arg on that post? | 22:09 |
| *** annegentle has quit IRC | 22:09 | |
| miguelgrinberg | no, much simpler than that, just send a POST request to the resource you want to copy, instead of addressing the collection | 22:10 |
| stevelle | what payload is posted? | 22:10 |
| miguelgrinberg | something like POST /v1/secrets/123 to clone secret #123 | 22:10 |
| miguelgrinberg | no payload | 22:10 |
| miguelgrinberg | the response is a 201, with a location of the new resource | 22:10 |
| stevelle | is that resource immutable? | 22:11 |
| elmiko | that might actually be the simplest | 22:11 |
| miguelgrinberg | probably not, but you would use PUT if you want to edit it | 22:11 |
| elmiko | stevelle: no, those resources can be updated with a PUT | 22:11 |
| elmiko | we are talking about secrets here, and you can create a new secret by POST to /secrets | 22:12 |
| elmiko | and then update with a PUT to /secrets/<id> | 22:12 |
| * stevelle engages on a mental tangent about the post secrets website | 22:12 | |
| elmiko | for example, you are allowed to create a secret with no payload, then update the payload later | 22:12 |
| stevelle | I have to say I'm not as comfortable with that option | 22:13 |
| elmiko | with which? | 22:13 |
| stevelle | #3 | 22:13 |
| elmiko | well, i'm sure they would love the discussion https://review.openstack.org/#/c/127823/ | 22:14 |
| elmiko | =) | 22:14 |
| stevelle | the PUT vs POST distinction is something I seem to be outvoted on however. | 22:14 |
| elmiko | imo it's still open for discussion, at least on this review | 22:15 |
| miguelgrinberg | quick survey of stackoverflow on the topic shows that the prefernce is the query string arg | 22:15 |
| stevelle | I know of no resources in OpenStack which are ever created or updated in such a way that PUT is appropriate because we never use complete resource representations. | 22:15 |
| elmiko | interesting | 22:15 |
| elmiko | is PUT supposed to use full resource? | 22:16 |
| miguelgrinberg | yes | 22:16 |
| elmiko | ahh | 22:16 |
| stevelle | That is how I have operated, yes. | 22:16 |
| elmiko | they might be doing it slightly oddly then | 22:16 |
| elmiko | http://docs.openstack.org/developer/barbican/api/quickstart/secrets.html#how-to-update-a-secret | 22:17 |
| stevelle | created_at and updated_at are examples of how the representations we make can be said to be complete. | 22:17 |
| stevelle | sorry, said to be incomplete | 22:17 |
| stevelle | all that metadata suggests to me that post should be used on create and update. As such I feel like encumbering POST with a copy operation might step on the toes of maybe someday using post correctly here, as impractical as that may be | 22:20 |
| elmiko | yea | 22:21 |
| miguelgrinberg | POST is rarely used on update, or maybe I don't understand what you are saying? | 22:21 |
| stevelle | if the server updates that updated_at field, ignoring the value sent in the update request, I view that as a violation of the idea of the 'complete resource representation' and thus not a good case for PUT. It's a bit purist I admit | 22:22 |
| elmiko | makes a certain amount of sense though | 22:23 |
| miguelgrinberg | my take on that is that you can have read-only fields in your representation | 22:23 |
| stevelle | miguelgrinberg: I will buy read-only but not server-managed. | 22:24 |
| miguelgrinberg | obviously you can't send the id to a POST request, you will find out the id once the resource is created | 22:24 |
| miguelgrinberg | yet it is part of the representation | 22:24 |
| miguelgrinberg | the created/modified_at fall in the same category | 22:24 |
| miguelgrinberg | the links to other resources same thing | 22:24 |
| stevelle | the server-generated id is an immutable, and doesn't change on update. | 22:25 |
| miguelgrinberg | isn't created_at the same? | 22:25 |
| stevelle | so the client has a complete representation | 22:25 |
| stevelle | so creating with a post, rather than a put, we agree on | 22:25 |
| miguelgrinberg | so your rule is that PUT must have a complete resource, but POST doesn't have to? | 22:26 |
| stevelle | correct | 22:26 |
| miguelgrinberg | ah ok | 22:26 |
| miguelgrinberg | seems arbitrary to me, so what do you do with id/created/modified_at in a PUT request? | 22:27 |
| miguelgrinberg | they're useless, yet by your rule they need to be included | 22:28 |
| stevelle | if your resources have those properties at all, you are basically saying "POST please" | 22:28 |
| stevelle | unless the values of them are not in the representation, and are header-bound | 22:29 |
| stevelle | and that is ok, your api just uses post and nobody has to think too hard :) | 22:30 |
| miguelgrinberg | so you have a PUT that you are not using for anything :) | 22:30 |
| stevelle | true | 22:31 |
| stevelle | there is a beauty in a place like openstack in saying 'dont worry your head about put vs post if you have an updated_at field managed by the server. use post' | 22:32 |
| stevelle | and reading the review I think I would agree with you elmiko on the copy endpoint. | 22:38 |
| *** alex_xu has quit IRC | 22:43 | |
| *** alex_xu has joined #openstack-api | 22:43 | |
| elmiko | please add comments with anything you guys might think for the review, the specifically asked for guidance from the wg | 22:45 |
| stevelle | I'm starring it for weekend reading, thanks | 22:45 |
| elmiko | awesome, thanks stevelle | 22:45 |
| *** elmiko is now known as _elmiko | 22:50 | |
| *** terrylhowe has quit IRC | 23:00 | |
| *** salv-orlando has quit IRC | 23:05 | |
| *** lucas-beer has quit IRC | 23:23 | |
| *** openstackgerrit has quit IRC | 23:39 | |
| *** openstackgerrit has joined #openstack-api | 23:39 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!