greptilian logo

IRC log for #rest, 2016-02-14

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:30 fuzzyhorns joined #rest
01:14 _ollie joined #rest
01:47 fuzzyhorns joined #rest
02:29 fuzzyhorns joined #rest
02:42 gigo1980__ joined #rest
04:05 mezod joined #rest
04:15 leolove joined #rest
04:24 cvander joined #rest
04:36 baweaver joined #rest
05:32 tbsf joined #rest
05:52 fuzzyhorns joined #rest
06:02 baweaver joined #rest
06:54 fuzzyhorns joined #rest
07:29 gigo1980__ joined #rest
07:36 talios joined #rest
08:56 fuzzyhorns joined #rest
09:35 leolove joined #rest
09:52 _ollie joined #rest
09:57 fuzzyhorns joined #rest
10:53 crdil left #rest
11:18 graste joined #rest
11:21 tbsf joined #rest
11:32 Macaveli joined #rest
11:42 tbsf joined #rest
11:55 baweaver joined #rest
11:58 gigo1980__ joined #rest
11:58 fuzzyhorns joined #rest
12:31 gigo1980__ joined #rest
12:59 fuzzyhorns joined #rest
13:24 gigo1980__ joined #rest
13:42 tbsf joined #rest
13:45 daxim joined #rest
13:58 baweaver joined #rest
14:00 fuzzyhorns joined #rest
14:47 fumanchu_ joined #rest
15:39 daxim joined #rest
15:52 tbsf joined #rest
15:58 baweaver joined #rest
16:02 fuzzyhorns joined #rest
16:15 tbsf joined #rest
16:22 fuzzyhorns joined #rest
16:52 tbsf joined #rest
17:20 mezod joined #rest
17:27 tbsf joined #rest
17:43 Left_Turn joined #rest
17:49 Left_Turn joined #rest
17:52 baweaver joined #rest
17:58 tbsf joined #rest
17:59 tbsf joined #rest
18:02 tbsf joined #rest
18:51 tbsf joined #rest
18:57 baweaver joined #rest
19:04 baweaver joined #rest
19:14 tbsf joined #rest
19:20 SJr Is it awful if I during a PUT of a resource I don't allow them to update say the last modified time but they do get that on output?
19:37 gigo1980__ joined #rest
20:02 trygvis SJr: no, that is fine
20:08 SJr Next question, if my representations typically include a segmenting/sharding/partitioning identifier should I keep it out of the URL for PUT and POST requests?
20:09 SJr e.g., if I have users and all users belong to a country,  PUT should be to /users (since the data will have it), but DELETE Could be to /users/{country}/{id}
20:13 asdf uh, you're doing a PUT for /users to update a specific user? why not update by PUTing to /users/{country}/{id}?
20:13 asdf or do you mean you're doing PUT /users for creating the user?
20:13 asdf if the latter, sure, that's fine - what matters is that the client doesn't guess the DELETE url, but instead it's told what it is
20:14 asdf (ie. creating it has a Location header with the right url, listing all the users yields the url, etc)
20:15 SJr asdf that's what I'm asking. It seems like /users/{country}/{id} is better (for the sake of discussion users can't move between countries) but the problem is the representation will also include country and id
20:16 SJr And so the question is, what happens if the country and id in the URI does not match the country and the id in the request body.
20:17 trygvis SJr: the client doesn't care what the URL look like
20:17 asdf nothing really needs to happen; often urls are considered opaque, and it's best if the clients don't try to analyze or construct urls on its own
20:17 SJr Yeah I understand that, but REST is suppose to be easy for humans to read and interpretable
20:18 SJr I have noticed in other applications that I have written things (different example)   /data/{stateId}/{cityId} but then city has a getState method, so you can get weird security issues where the cityId doesn't actually have the stateId associated with it.
20:18 SJr So I would like to avoid it.
20:19 SJr This is my first REST service I've implemented
20:19 trygvis when you create a resource you can include a Location header which the client can use to update and/or delete the resource
20:20 SJr Yeah I understand that
20:20 trygvis that location can include a shard id if you feel like it
20:20 trygvis problem solved, no?
20:20 SJr Yeah
20:20 SJr I understand that part
20:21 SJr Actually a simpler question is the following
20:21 trygvis if the object moves to a different shard you can redirect the client to the current location. nice!
20:21 SJr Yeah I know
20:21 trygvis web scale!!
20:22 SJr But actually lets just talk about /customers/{id}
20:22 trygvis I refuse to talk about URL values
20:22 SJr Why?
20:23 trygvis they're never relevant
20:23 SJr I think it is but I'm a beginner.
20:23 SJr If I am using PUT to update a customer, then it seems that it should be /customers/{id} , but it also seems like the representation may also include that id. So there is a confused deputy problem if I specify it twice isn't there
20:25 trygvis no, it shouldn't be /customers/{id}
20:25 SJr It seems very very non-rest to have every customer be updated at /customers/
20:25 trygvis it should be: X
20:25 trygvis it should be the value the client got when it created the resource
20:25 SJr Yes that part I get
20:26 SJr I am not arguing about the actual values of the URL.
20:26 trygvis so create a question without refering to a particular path then
20:28 SJr Fine, when I create a Customer I post to a specific generic resource, for two customers it will return urls X and Y, where X != Y.  Further updates to the customers should be PUT requests to X and Y, and those updates will probably include identifiers for X and Y in their bodies.
20:28 SJr So when I do a put, I get told one location X via the HTTP Resource, and another location Y via the body of the representation.
20:29 trygvis usually the URL itself sever as identifiers for the resource, not something in their body
20:30 trygvis and you almost always only create a single resource
20:30 SJr trygvis, every book I've been reading has the XML and/or JSON returning a link to itself and I think the body of representations should do this as a rule.
20:31 SJr Otherwise the representation by itself needs extra meta-data to be useful.
20:31 trygvis so you post to $customerCollection, and you get a URL to $customer1 back
20:31 SJr Yeah I get that.
20:31 trygvis ah, ok, I though you just said that you would get two URLs back from a single request
20:31 SJr No
20:32 SJr Do you understand what I mean when I say confused deputy?
20:34 trygvis nope
20:36 trygvis can you create a paste of what your request and response would look like when you create the customer?
20:38 SJr http://www.pastebin.ca/3373876
20:38 SJr Does that put make sense?
20:40 trygvis the first is the response from a GET and the second is the body of a PUT?
20:40 SJr Yeah
20:42 trygvis looks good to me
20:42 SJr Okay so what if I PUT to "http://restservice.com:8080/customers/3" something with a link uri of : "http://restservice.com:8080/customers/47"
20:45 trygvis the server can choose to ignore the links (which I think is about what ever deployed server to) or it can respond with 400 bad request
20:45 SJr Okay thank you
20:46 trygvis now I think I see what you meant with two urls too :)
20:50 SJr yeah
20:50 SJr it's fine I've been thinking about it, and yes I should be using URLs more and not Ids that the client is suppose to be reconstructing.
20:52 trygvis :)
21:00 SJr Thank you trygvis
21:01 trygvis np
21:29 cvander joined #rest
21:34 leolove left #rest
21:39 tbsf joined #rest
21:54 fuzzyhorns joined #rest
22:28 baweaver joined #rest
23:17 baweaver joined #rest
23:39 fuzzyhorns joined #rest

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

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