IRC log for #rest, 2015-03-02

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

All times shown according to UTC.

Time	Nick	Message
00:11		warehouse13 joined #rest
00:30		digitalsanctum joined #rest
00:32		fumanchu joined #rest
00:48		pgicxplzs joined #rest
01:02		azer_ joined #rest
01:18		shrink0r_ joined #rest
01:20		Left_Turn joined #rest
02:46		Jefffrey joined #rest
02:49		shrink0r joined #rest
04:47		dreamdust joined #rest
08:18		azer_ joined #rest
08:34		Andre-B joined #rest
08:51		azer_ joined #rest
08:56		interop_madness joined #rest
09:30		Gue______ joined #rest
09:36		shrink0r joined #rest
09:47		_ollie joined #rest
09:49		Left_Turn joined #rest
10:24		graste joined #rest
11:23		vanHoesel joined #rest
11:43		whatacold joined #rest
11:51		Jefffrey joined #rest
12:12		vanHoesel joined #rest
12:24		mezod joined #rest
12:52		jcromartie joined #rest
13:07		azer_ joined #rest
13:10		azer_ joined #rest
13:57		Mxyzpltk joined #rest
14:19		shrink0r joined #rest
15:01		Mxyzpltk_ joined #rest
15:02		jackalista joined #rest
15:05		saml joined #rest
15:45		proteusguy joined #rest
15:55		Mxyzpltk__ joined #rest
15:57		seantallen joined #rest
16:10		dEPy joined #rest
16:23		Mxyzpltk__ joined #rest
16:40		Mxyzpltk__ joined #rest
16:55		Mxyzpltk__ joined #rest
17:12		lemur joined #rest
17:12		interop_madness joined #rest
17:22		fumanchu_ joined #rest
17:28		vanHoesel joined #rest
17:37		shrink0r joined #rest
17:50		Mxyzpltk__ joined #rest
18:02		Mxyzpltk joined #rest
18:13		Andre-B joined #rest
18:23		azr joined #rest
18:32		Judasbricot joined #rest
18:43		graste joined #rest
19:05		kibibyte joined #rest
19:05	kibibyte	hi
19:05	kibibyte	anytone here
19:07	Judasbricot	hi
19:10	kibibyte	i have question about proper rest design : is it good idea to have some resources protected by i.e password and some not like : /users/{id}/ (no password) /users/{id}/orders/2 (password needed)
19:13	Judasbricot	i guess for authentification purpose, you should use something like OAuth2
19:15	kibibyte	but abstracting from authentication
19:16	whartung	there's nothing wrong with having restrictions at any granularity kibibyte
19:16	whartung	simple example
19:16	whartung	one person can see /users/1
19:16	whartung	while another can see /users/2
19:16	whartung	but they can't see each other
19:17	whartung	nor is it a problem if user A sees one version of /users/1 while user B sees a different versions because they have different rights to the data
19:19	kibibyte	whartung, and how to solve issue like: i forgot my password . i.e i have resource like /users/me /pass. /user/me is password protected . but to reset my password i need to have i.e POST /users/me /pass not protected
19:19	whartung	unless you;re sharing trust (Service X wants to access User U's data at Service Y), there's no reason to do anything beyond HTTP BASIC or DIGEST
19:20	kibibyte	and its kind a inconsistent that /user/me is password protected and POST /users/me /pass not protected
19:20	kibibyte	./users/me/pass not protected
19:21	kibibyte	so how to di it right way
19:21	whartung	/shrug a good security framework basically gives you an Identity and a the Identity gives you a list of Roles/Privileges/Rights/whatever you want to call them. It's up to your code interpret the rights properly when you process the request.
19:21	kibibyte	consistent
19:22	kibibyte	i know but on rest URL level
19:22	whartung	clearly a high level "secure everything" approach won't work in this case.
19:22	whartung	you need finer grain control
19:23	whartung	why not simply POST 'me' to /recoverpassword ?
19:24	fumanchu_	a stateful way to spell that would be to have a "has_valid_password" attribute which the client sets to False
19:25	whartung	but does setting that state necessary start the workflow to do tha actual recovery vs simply record the fact of the status?
19:26	fumanchu_	that's up to the implementation hidden behind the API
19:26	whartung	you coul dargue the status is set by the start of the recovery process, rather than the other way around.
19:27	fumanchu_	not in a state-transfer architecture
19:27	fumanchu_	you could argue it's better to not follow the stateful arch here, which I might agree with :)
19:27	whartung	I'm not a big fan of state changes having side effects, myself, I like to be more pro-active (outside of things like logging and auditing)
19:28	kibibyte	hm /recoverpassword > i thought its good practive tou not use verbs
19:28	* fumanchu_	points at #rpc on the other side of the IRC server
19:29	_ollie	kibibyte: nobody should care about what letters a URI consists of…
19:29	_ollie	no client, to be precise…
19:29	fumanchu_	thanks _ollie :)
19:30	kibibyte	no but like PUT /users/1/password seems better than /users/1/update_password
19:30	_ollie	it couldn't matter less…
19:30	whartung	that said, I find /recover_password easier to code, work with and debug instead of /875776D3-9309-4CB2-8933-6747DE6972DA
19:31	fumanchu_	it couldn't matter less to the machine executing the navigation of the application state. it matters a great deal to the human coding that app when reading your docs
19:31	_ollie	fumanchu_: not if you're using hypermedia…
19:31	fumanchu_	yes, even then
19:31	fumanchu_	hypermedia is not capable of machine-encoding all semantics
19:32	kibibyte	whartung, and what in case of users: you gonna have ; /useradd /userdel /userupdate and you can achive same with POST, PUT,DELETE /user/
19:32	whartung	the big point kibibyte is not that recover_password is a good or bad "URL", it's that typically when people fixate on the URLs, they're focusing on the wrong part of the problem of a REST design
19:33	whartung	find, POST to /password_recovery_queue
19:33	kibibyte	hm
19:33	kibibyte	ugly
19:34	* whartung	snorts
19:34	kibibyte	i have PUT /users/{id}/password for changing password by logged user. Now how to reset it same way
19:35	whartung	POST the user id to /password_recovery_queue, it returns a url /password_recovery_activity/12345 that you can monitor and see what's going on with that specific recovery.
19:35	whartung	the processes are different, you can PUT to .../password all day long
19:35	fumanchu_	and you might POST a token you get in email to that same 12345 resource
19:35	whartung	but that's a far cry from password recovery which deals wth emails, and validation, and all the happy stuff.
19:36	kibibyte	whartung, yes i need to snd mail with hash
19:36	kibibyte	and based on this hash password will be change d
19:37	whartung	REST is about resources. Services ARE resources. Password Recovery is a Service
19:37	kibibyte	hm
19:37	fumanchu_	kibibyte: that's what I meant by "token" == the hash
19:39	kibibyte	so maybe POST /users/{id}//password_recovery <- create token and send via email , PUT /users/{id}/password_recovery change password based on token
19:40	kibibyte	???
19:41	kibibyte	what you think
19:41	* fumanchu_	writes long answer
19:41		shrink0r joined #rest
19:41	whartung	I think that having access to the password recovery acitity is better
19:42	kibibyte	whartung, what you mean ? what url do you propose
19:42	whartung	I did it earlyer
19:42	kibibyte	oh this one /password_recovery_queue
19:43	whartung	you can root taht whereever you want, I'm talking about the resource that it created
19:57		shrink0r joined #rest
20:06		shrink0r_ joined #rest
20:10		shrink0r joined #rest
21:14		AnxiousGarlic joined #rest
21:14		AnxiousGarlic left #rest
23:05		shrink0r_ joined #rest

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