| Time |
S |
Nick |
Message |
| 01:31 |
|
|
talios joined #rest |
| 01:39 |
|
|
DrCode joined #rest |
| 02:13 |
|
|
rosstuck joined #rest |
| 03:18 |
|
|
fumanchu_ joined #rest |
| 03:39 |
|
|
tr3online joined #rest |
| 04:06 |
|
|
proteusguy joined #rest |
| 04:20 |
|
|
Arahael joined #rest |
| 04:21 |
|
Arahael |
So, how does one implement the 'code-on-demand' feature of REST today? |
| 04:21 |
|
Arahael |
(In what situations does it even make sense?) |
| 04:29 |
|
talios |
dynamically generated business logic/rules from server state. server coud generate code on the fly to ship to clients. |
| 04:47 |
|
Arahael |
Yes, but what's a concrete, practical example? |
| 06:14 |
|
tmoore |
Arahael: the script element in HTML :-) |
| 06:19 |
|
tmoore |
I think it's a pretty exotic feature otherwise... I've never heard of any other example |
| 06:53 |
|
Arahael |
Yeah, I'm struggling to think of examples myself, other than xslt's in the xml case. |
| 07:07 |
|
|
interop_madness joined #rest |
| 07:51 |
|
|
rosstuck joined #rest |
| 08:02 |
|
|
graste joined #rest |
| 08:50 |
|
|
proteusguy joined #rest |
| 09:01 |
|
|
martinfilliau joined #rest |
| 09:06 |
|
|
fumanchu joined #rest |
| 09:25 |
|
|
Left_Turn joined #rest |
| 09:26 |
|
|
Arahael left #rest |
| 09:54 |
|
|
talios joined #rest |
| 10:04 |
|
|
shrink0r joined #rest |
| 10:09 |
|
|
fumanchu_ joined #rest |
| 10:11 |
|
|
fumanchu1 joined #rest |
| 11:17 |
|
|
martinfilliau joined #rest |
| 11:36 |
|
|
tr3onlin_ joined #rest |
| 12:07 |
|
|
tr3online joined #rest |
| 12:18 |
|
|
martinfilliau joined #rest |
| 13:08 |
|
|
tr3onlin_ joined #rest |
| 13:14 |
|
|
rosstuck joined #rest |
| 13:55 |
|
|
saml joined #rest |
| 14:09 |
|
|
tr3online joined #rest |
| 14:26 |
|
|
proteusguy joined #rest |
| 14:39 |
|
|
tr3onlin_ joined #rest |
| 15:10 |
|
|
tr3online joined #rest |
| 15:17 |
|
|
nkoza joined #rest |
| 15:26 |
|
|
tr3online joined #rest |
| 15:36 |
|
|
fumanchu joined #rest |
| 15:44 |
|
|
pezra joined #rest |
| 16:25 |
|
|
fumanchu_ joined #rest |
| 16:32 |
|
|
proteusguy joined #rest |
| 16:37 |
|
|
danfinch joined #rest |
| 16:39 |
|
|
fumanchu joined #rest |
| 16:51 |
|
|
fumanchu_ joined #rest |
| 16:53 |
|
|
pezra joined #rest |
| 17:04 |
|
|
fumanchu joined #rest |
| 17:17 |
|
|
fumanchu_ joined #rest |
| 18:31 |
|
|
shrink0r joined #rest |
| 18:57 |
|
|
tr3online joined #rest |
| 19:20 |
|
|
shrink0r joined #rest |
| 19:40 |
|
|
saml joined #rest |
| 20:26 |
|
|
chrismetcalf left #rest |
| 20:29 |
|
|
talios joined #rest |
| 20:32 |
|
|
adaro joined #rest |
| 20:40 |
|
|
shrink0r1 joined #rest |
| 20:43 |
|
|
charlie_ joined #rest |
| 20:50 |
|
|
danizord joined #rest |
| 21:09 |
|
|
Left_Turn joined #rest |
| 21:31 |
|
|
talios joined #rest |
| 21:48 |
|
|
breerly joined #rest |
| 21:48 |
|
breerly |
Hello |
| 21:49 |
|
breerly |
Is there a good way to represent "asking if a new/existing resource is valid for create/update" before actually attempting to do the operation? |
| 21:49 |
|
whartung |
what does that mean? "is valid for create/update" |
| 21:49 |
|
whartung |
valid how? |
| 21:51 |
|
breerly |
something like so |
| 21:51 |
|
breerly |
POST /cats |
| 21:51 |
|
breerly |
throws client error because the cat name is not unique |
| 21:51 |
|
breerly |
I want to model an endpoint that lets me check that "before" I submit |
| 21:52 |
|
whartung |
well, you could GET /cats |
| 21:52 |
|
whartung |
if you don't get a 404, it exists. |
| 21:52 |
|
breerly |
Right |
| 21:52 |
|
breerly |
but as the validation logic gets more complex, should I encapsulate that in the service? |
| 21:52 |
|
breerly |
i.e. pushing that onto the client seems a bit odd, especially when the client has the single question "is this resource valid" |
| 21:52 |
|
whartung |
how is the logic getting more complex? |
| 21:53 |
|
breerly |
hard to say at the moment |
| 21:53 |
|
whartung |
because there are all sorts of 400 codes that address different situations |
| 21:53 |
|
breerly |
complex validation like cross field validation, date/credit card validation, verifying account numbers etc... |
| 21:53 |
|
breerly |
sure sure |
| 21:54 |
|
breerly |
but if the client wants to know ahead of time, i.e. wants a way to check the validity of a resource |
| 21:54 |
|
breerly |
I suppose an RPC endpoint… GET /cats/is_valid -> {"name":"fluffy"} |
| 21:54 |
|
breerly |
feels kind of mucky |
| 21:54 |
|
whartung |
in those cases, you can't know if it's valid until all the data the validation is based upon is sent. |
| 21:54 |
|
breerly |
correct |
| 21:54 |
|
whartung |
but then why not simply submit it? |
| 21:54 |
|
breerly |
thats true |
| 21:55 |
|
breerly |
for UIs, for example |
| 21:55 |
|
whartung |
what's the difference between POST /validationthing { payload } and get back error vs POST /legitresource { payload } ? |
| 21:55 |
|
breerly |
or if you want a confirm step? |
| 21:55 |
|
whartung |
well that's a different problem completely |
| 21:56 |
|
breerly |
the confirm step i suppose is the validation |
| 21:56 |
|
breerly |
i suppose from a UI step, you want to know the cat is valid before submitting it |
| 21:57 |
|
whartung |
right, but here's the detail |
| 21:58 |
|
whartung |
from a REST point of view, that application semantic is really not important. |
| 21:58 |
|
whartung |
it's kind of out of scope |
| 21:58 |
|
whartung |
but at the same time |
| 21:58 |
|
whartung |
you don't want a "light the match" test per se |
| 21:59 |
|
whartung |
where yea, the match lights, test passes - but now you have no match |
| 21:59 |
|
whartung |
now, you could add a header |
| 21:59 |
|
whartung |
X-Validate |
| 21:59 |
|
whartung |
that does everything to the process but the "commit" so to speak |
| 22:07 |
|
breerly |
nice |
| 22:07 |
|
breerly |
i like that |
| 22:31 |
|
|
`0660 joined #rest |
| 22:41 |
|
|
tr3online joined #rest |
| 22:42 |
|
|
tr3online joined #rest |
| 23:13 |
|
|
blongden joined #rest |
