IRC log for #rest, 2017-09-28

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

All times shown according to UTC.

Time	Nick	Message
01:43		leclerc joined #rest
03:49		KevBurnsJr joined #rest
06:35		wittysense joined #rest
06:50		Haudegen joined #rest
06:53		_ollie joined #rest
07:57		interop_madness joined #rest
08:36		wittysense joined #rest
10:07		KevBurnsJr joined #rest
10:13		drcode joined #rest
10:28		drcode joined #rest
10:38		wittysense joined #rest
11:06		shodan` joined #rest
12:09		Haudegen joined #rest
12:39		wittysense joined #rest
13:04		wittysense joined #rest
15:54		jenia joined #rest
15:54	jenia	hello everyone
15:54	jenia	is any Ajax app a REST app?
15:55	mdk	jenia: no
15:55	jenia	mdk, I'm reading this article and don't understand it completlyhttps://stackoverflow.com/questions/19884295/soap-vs-rest-differences
15:55	jenia	https://stackoverflow.com/questions/19884295/soap-vs-rest-differences
15:56	jenia	mdk, what are examples of REST apps?
15:57	mdk	jenia: api.github.com is a service that I think respects some of the REST "philosophy"
15:57	jenia	thanks
15:58	mdk	jenia: REST is about discoverability, respecting HTTP semantics (RFC 7231), representing states (instead of procedures), …
15:59	jenia	mdk, can I ask you more on that point? cause in the wiki it says:
15:59	jenia	"using a uniform and predefined set of stateless operations"
15:59	jenia	https://en.wikipedia.org/wiki/Representational_state_transfer
16:00	mdk	jenia: Ajax is "just" "Let's use asynchronous Javascript calls to transfer XML", there's no "let's do it cleanly" in it, just a lot of "we can do it" (which is obviously better that the previous "we just can't"
16:00	mdk	)
16:00	jenia	lol
16:00	mdk	and SOAP is all about RPC (Remote Procedure Call), not about state transfer
16:00	jenia	alright
16:01	jenia	so the operations have no state
16:01	jenia	but I see in api.github: https://github.com/settings/connections/applications{/client_id}
16:01	jenia	but client_id is a state no?
16:01	mdk	So in SOAP you're expressing "Call the new_method(login, password) procedure", in REST you're expressing "Add this user to the collection of existing users"
16:02	mdk	jenia: As long as there's a database server-side, yes, there's a state
16:02	mdk	You will POST/PUT/PATCH data, obviously (a new message, whatever), this will change a state
16:03	jenia	mdk, so this phrase in the wiki is false I guess: using a uniform and predefined set of stateless operations
16:03	mdk	The stateless part is about operations, (interactions) between the server and the client being stateless
16:04	mdk	Let me find an example…
16:04	jenia	alright. thank you
16:04	mdk	A statefull operation would be "call login(username password) to get a session id, then use this session_id to call add_message(text)
16:04	mdk	"
16:05	jenia	okay. got it
16:05	jenia	there's a state between the two ops
16:05	jenia	and in REST how would that look?
16:05		interop_madness joined #rest
16:05		interop_madness joined #rest
16:06	mdk	In REST I would just use HTTPS and basic auth, or maybe a JWT, so you just skip the "login" part, either the backend receive the new message with the login:password of the user (basic auth), or a signed token prooving the user is who he say he is (JWT)
16:07	mdk	There may be other REST"y" ways to do it, I'm not Roy Fielding, and I'm not perfect
16:07	jenia	mdk, alright. thanks. no one is perfect :)
16:08	mdk	The idea is each operation by itself is meaningfull, it's not part of a sequence. But on the other hand, there's obviously an application state : you can't pay a bill if you have still not bought the thing
16:08	jenia	yes
16:09	jenia	that's what I can't wrap my head around
16:09	mdk	So the state exist, the sequence exist, but only imposed by the semantics of the thing you're implementing
16:09	mdk	You can't POST an issue on not-yet existing project, and so on
16:10	mdk	So don't mind about the statelessness part, maybe focus on the HTTP semantics, RFC 7231 is very interesting on the subject
16:11	mdk	Typically the safe and idempotent methods : https://tools.ietf.org/html/rfc7231#section-4.2
16:11	mdk	Basically GET is idempotent, you can read a thing twice, it's not expected to break nothing
16:11	mdk	PUT is "Put this here", you can put the same thing twice in the same place, it won't break nothing
16:12	mdk	POST is not idempotent, post may mean "Add to the collection", adding a coffee twice on an order list is NOT equivalent to add it once
16:13	mdk	Alongside with those notions, the If-Match and If-None-Match are really interesting :
16:13	jenia	okay. what are those?
16:13	mdk	Imagine this sequence
16:14	mdk	I GET /message/1
16:14	mdk	it have a ETag header telling me it's version 123 of the message
16:14	mdk	I modify it (fix a typo \o/)
16:14	mdk	now I PUT the modified message on /message/1 with a If-Match etag 123
16:15	mdk	If you modified the message before me, I would overwrite your modification, it would be lost
16:15	mdk	but with the if-match the server should reply with a conflict
16:15	mdk	so now, your client knows there's a problem, and it should GET again and resolve the conflict (some code to do here, HTTP don't care about your implementation)
16:16	mdk	HTTP is cool for this kind of mechanisms, and REST is all about "use HTTP clealy, it already provides a lot to do things meaninfully"
16:17	jenia	hummmm
16:17	jenia	alright thanks
16:17	mdk	sry I have to go, going to a salt meetup, hope it will be cool ^^
16:17	mdk	take care
16:18	jenia	you too
16:18	jenia	thank you!!
16:30		drcode joined #rest
16:47		drcode joined #rest
16:48		Haudegen joined #rest
16:59		drcode joined #rest
17:27	leclerc	mdk: in many cases you're not just using HTTP and the client is not just seeing HTTP, but you're basically mapping API specifics ad-hoc to existing HTTP mechanisms, adding additional intent to them that the client should be aware of.
17:27	leclerc	mdk: in the end it's no better than a custom interface.
18:18		wittysense joined #rest
19:48		jenia joined #rest
20:14		_ollie joined #rest

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