| Time |
S |
Nick |
Message |
| 01:14 |
|
|
riddle joined #rest |
| 08:10 |
|
|
Haudegen joined #rest |
| 08:26 |
|
|
interop_madness joined #rest |
| 09:26 |
|
mdk |
Hum, I have a question: What if, during a POST (so, on a collection), a client does a GET on this collection. The client may obtain its own document in the GET response *before* getting the result of the POST, though not being capable of recognizing it, displaying it, and causing a graphical bug (considering the client application was already displaying the POSTed document nicely with style being unambiguous |
| 09:26 |
|
mdk |
about the fact that "this document is not yet synced"). (That can be resolved some "time" later, when the POST will reply, by merging both documents, after the user spotted the duplicate, causing "another bug fixing the first done": a document dissapearing to deduplicate the content). |
| 09:27 |
|
trygvis |
hm, I don't quite follow |
| 09:27 |
|
mdk |
:-( |
| 09:29 |
|
* mdk |
is trying to clarify |
| 09:30 |
|
trygvis |
:) |
| 09:39 |
|
mdk |
→ https://dpaste.de/L9a9 I explained the "right" way I understand of how things should properly go, and the bug I found in my implementation of it |
| 09:42 |
|
asdf |
yep; if you need that, i'd make the client ids "official"; maybe just a uuid4? |
| 09:43 |
|
mdk |
asdf: I'm hardly trying to avoid this, but yes this is clearly something that can work |
| 09:44 |
|
mdk |
asdf: but this "surrogate client id" has *no meaning* so I really don't want it in my API (legitimate?) |
| 09:44 |
|
asdf |
does the regular id have meaning? |
| 09:45 |
|
mdk |
asdf: no, surrogate id too þ |
| 09:46 |
|
asdf |
what if the uuid-client-id was the only id, not surrogate (then you'd be able to PUT /<id> instead, too) |
| 09:46 |
|
mdk |
asdf: though used in the URLs to identify the document, yet all URLs are given, so the "id" attribute is of (almost ?) no use, the "self url" should be enough |
| 09:47 |
|
asdf |
(that's probably too big of a change, though) |
| 09:48 |
|
mdk |
asdf: Yes, it should work, and yes it's too big of a change too as I'm building this API over an existing / working system that I can't break, I'll even probably find a whole lot of places where the ID is enforced to be an integer |
| 09:49 |
|
mdk |
So the first part of my paste looked like the right way to do thigs, until I found this "problem" |
| 09:51 |
|
mdk |
Locks, client-side, to "freez" display while a POST is done *may* solve the problem a bit, introducing a lot of complexity and potential bugs too like ("Hey, when I POST, the app freez for one second and then BOOM I get a whole lot of content displayed at once" |
| 09:55 |
|
mdk |
Maybe look at HTTP code 202 https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html to try to win the race during the POST … but that's just "throwing some milliseconds to the race", that's not really fixing the bug. |
| 10:04 |
|
* mdk |
is going to eat (France), will backlog in like one hour |
| 10:09 |
|
asdf |
hey don't eat France |
| 10:10 |
|
asdf |
(but yeah, i mean, i dont think there's much you can do otherwise, that's just distributed systems for you) |
| 11:37 |
|
mdk |
Did not eat France þ |
| 11:37 |
|
mdk |
(still thinking but yes I have no idea for the moment on how to expose this nicely) |
| 13:12 |
|
|
Haudegen joined #rest |
| 15:55 |
|
|
wsieroci joined #rest |
| 16:06 |
|
|
tbsf joined #rest |
| 17:11 |
|
|
ResidentBiscuit joined #rest |
| 17:24 |
|
|
Haudegen joined #rest |
| 17:34 |
|
|
wsieroci joined #rest |
| 17:47 |
|
|
whartung joined #rest |
| 18:18 |
|
|
zama joined #rest |
| 18:21 |
|
|
tbsf joined #rest |
| 18:27 |
|
|
tbsf joined #rest |
| 18:35 |
|
|
tbsf joined #rest |
| 19:36 |
|
|
tbsf joined #rest |
| 19:37 |
|
|
tbsf joined #rest |
| 20:04 |
|
|
tbsf joined #rest |
| 20:09 |
|
|
ResidentBiscuit joined #rest |
| 20:09 |
|
|
ResidentBiscuit joined #rest |
| 20:09 |
|
|
ResidentBiscuit joined #rest |
| 20:10 |
|
|
ResidentBiscuit joined #rest |
| 20:11 |
|
|
ResidentBiscuit joined #rest |
| 20:21 |
|
|
wsieroci joined #rest |
| 21:08 |
|
|
ForeignBiscuit joined #rest |
| 22:50 |
|
|
tbsf joined #rest |
| 22:58 |
|
|
tbsf joined #rest |
