IRC log for #rest, 2016-02-14

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

All times shown according to UTC.

Time	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

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