| Time |
S |
Nick |
Message |
| 00:04 |
|
|
Andre-B joined #rest |
| 00:14 |
|
|
zama joined #rest |
| 00:14 |
|
|
igitoor joined #rest |
| 00:15 |
|
|
igitoor joined #rest |
| 00:37 |
|
|
shrink0r_ joined #rest |
| 01:29 |
|
|
shrink0r joined #rest |
| 01:31 |
|
|
shrink0r_ joined #rest |
| 01:46 |
|
|
KevBurnsJr joined #rest |
| 02:02 |
|
|
shrink0r joined #rest |
| 02:20 |
|
|
KevBurnsJr joined #rest |
| 02:47 |
|
|
shrink0r_ joined #rest |
| 03:13 |
|
|
lemur joined #rest |
| 03:18 |
|
|
shrink0r joined #rest |
| 03:49 |
|
|
shrink0r_ joined #rest |
| 04:54 |
|
|
ewalti joined #rest |
| 07:21 |
|
|
fumanchu joined #rest |
| 07:29 |
|
|
fumanchu joined #rest |
| 07:30 |
|
|
Andre-B joined #rest |
| 07:53 |
|
|
graste joined #rest |
| 08:18 |
|
|
vanHoesel joined #rest |
| 08:21 |
|
|
interop_madness joined #rest |
| 08:22 |
|
|
fumanchu_ joined #rest |
| 08:27 |
|
|
shrink0r joined #rest |
| 09:07 |
|
|
quimrstorres joined #rest |
| 09:15 |
|
|
_ollie joined #rest |
| 09:16 |
|
|
quimrstorres joined #rest |
| 10:03 |
|
|
vanHoesel joined #rest |
| 10:18 |
|
|
vanHoesel joined #rest |
| 10:36 |
|
|
_ollie joined #rest |
| 11:05 |
|
|
mezod joined #rest |
| 11:36 |
|
|
Andre-B joined #rest |
| 11:39 |
|
|
Left_Turn joined #rest |
| 12:06 |
|
|
vanHoesel joined #rest |
| 12:28 |
|
|
quimrstorres joined #rest |
| 12:35 |
|
|
quimrsto_ joined #rest |
| 12:37 |
|
|
quimrstorres joined #rest |
| 12:40 |
|
|
vanHoesel joined #rest |
| 14:13 |
|
|
ewalti joined #rest |
| 14:44 |
|
|
wsiqueir joined #rest |
| 14:55 |
|
|
Jefffrey joined #rest |
| 15:28 |
|
|
rhyselsmore joined #rest |
| 16:15 |
|
|
lemur joined #rest |
| 16:17 |
|
|
ewalti joined #rest |
| 16:45 |
|
|
lemur joined #rest |
| 17:09 |
|
|
tieTYT2 joined #rest |
| 17:45 |
|
|
Andre-B joined #rest |
| 18:01 |
|
|
ewalti joined #rest |
| 18:22 |
|
|
whartung joined #rest |
| 18:55 |
|
|
_ollie1 joined #rest |
| 19:31 |
|
|
ModusPwnens joined #rest |
| 19:32 |
|
ModusPwnens |
if you have nested resources (e.g. projects and tasks for those projects), is it expected that when you make a call to get the top level resource, it has information about its sub resources? |
| 19:32 |
|
ModusPwnens |
for example, if you make a GET to /projects/1, would one expect that the returned representation has information about all the tasks associated with that project? |
| 19:33 |
|
fumanchu_ |
yes. but how much is the question. |
| 19:33 |
|
fumanchu_ |
at the barest minimum, you expect links to them (or perhaps URL Templates) |
| 19:33 |
|
ModusPwnens |
Okay, so at the bare minimum, if you are declaring something as a subresource in your url schemes, the parent resources need to at least have locations for those subresources? |
| 19:33 |
|
sfisque |
i guess it would depend on what the uri reprensents? is it a containment hiearchy or a "node->edge->node" type graph? |
| 19:34 |
|
fumanchu_ |
after that, you have to weigh how large the response is vs how many calls you'd have to make to get the same info some other way |
| 19:34 |
|
ModusPwnens |
Is this documented in rest somewhere? |
| 19:34 |
|
fumanchu_ |
not specifically |
| 19:34 |
|
fumanchu_ |
I keep meaning to write it when I'm independently wealthy |
| 19:35 |
|
ModusPwnens |
Oh. Then is it actually a hard requirement of 'rest'? |
| 19:35 |
|
fumanchu_ |
it's a principle of REST that the client achieves their desired application state by following links |
| 19:36 |
|
fumanchu_ |
and it's a principle of REST that the representations be explicit about their cachability, which affects the tradeoff of size vs frequency |
| 19:36 |
|
ModusPwnens |
Okay so given a root resource, you should be able to interact with all the other resources you need to by following information given to you in that root resource? |
| 19:37 |
|
fumanchu_ |
navigate to, yes, via a tree of links |
| 19:37 |
|
ModusPwnens |
Yeah, I see that as point 6 here: https://code.google.com/p/implementing-rest/wiki/RESTAPIRules |
| 19:37 |
|
ModusPwnens |
Okay cool. Thanks! |
| 19:39 |
|
|
quimrstorres joined #rest |
| 19:46 |
|
|
upasana joined #rest |
| 19:56 |
|
|
graste joined #rest |
| 20:18 |
|
|
arbelos joined #rest |
| 20:41 |
|
arbelos |
Hello. |
| 20:42 |
|
whartung |
o/ |
| 20:45 |
|
trygvis |
\o |
| 20:46 |
|
whartung |
o/\o |
| 20:46 |
|
arbelos |
advanced |
| 20:47 |
|
trygvis |
\o\ /o/ \o\ |
| 20:47 |
|
whartung |
those are teh best concert songs... |
| 20:48 |
|
arbelos |
So, it is not considered RESTful to expose an action as an URL from what I understand |
| 20:49 |
|
arbelos |
In this case, I have a resource "product" |
| 20:49 |
|
arbelos |
and I need to keep track of product stock |
| 20:50 |
|
arbelos |
which involves some movement in various directions |
| 20:50 |
|
arbelos |
and that can most of the time be done "behind the scenes" |
| 20:51 |
|
arbelos |
but let's say I need to have some way for consumers to be able to make stock adjustments |
| 20:52 |
|
whartung |
PUT /stock_adjustment |
| 20:52 |
|
arbelos |
but adjustment is an action then, or? |
| 20:52 |
|
whartung |
no, it's a stock adjustment. |
| 20:52 |
|
whartung |
it's like a credit memeo |
| 20:52 |
|
whartung |
memo |
| 20:53 |
|
whartung |
(if you know anything about accounting) |
| 20:53 |
|
arbelos |
not much, but I can imagine |
| 20:53 |
|
arbelos |
or pretend |
| 20:53 |
|
whartung |
simple example |
| 20:53 |
|
whartung |
say you buy some stuff from amazon |
| 20:53 |
|
whartung |
you get 1 dvd and 1 pair of socks |
| 20:53 |
|
arbelos |
sure |
| 20:54 |
|
whartung |
that's an Order |
| 20:54 |
|
arbelos |
right |
| 20:54 |
|
whartung |
well, the socks don't fit |
| 20:54 |
|
whartung |
so what do you do? |
| 20:54 |
|
arbelos |
return them |
| 20:54 |
|
whartung |
PUT /return { socks: 1 } |
| 20:54 |
|
asdf` |
(well you can't return just one sock) |
| 20:55 |
|
arbelos |
1 pair perhaps |
| 20:55 |
|
whartung |
that's an actual artifact, taht resource represents the transaction |
| 20:55 |
|
whartung |
just the fact that it exists |
| 20:55 |
|
arbelos |
so return is a resource |
| 20:55 |
|
whartung |
an easy way to think of REST-ish architecture, at a basic level, is imagine you need to have someone else do something. What would they need in order to do it properly? |
| 20:56 |
|
whartung |
the Return Department would need a reference to the Order, and the item(s) returned. |
| 20:56 |
|
whartung |
so you create a document and send it to them. |
| 20:56 |
|
whartung |
if you later GET /return/1234 |
| 20:57 |
|
whartung |
you can see the status of the return (Complete, In Process, Rejected), etc. |
| 20:57 |
|
whartung |
GET /return?order=http://example.com/order/1234 can give you a list of returns for a specific order |
| 20:58 |
|
whartung |
etc |
| 20:58 |
|
arbelos |
ok, that makes sense |
| 20:58 |
|
whartung |
practically, pragmatically, etc. etc. it's not a hard and fast rule. But it helps direct the discussion |
| 20:58 |
|
whartung |
you will find that you will need many more resources than you thought originally. |
| 20:58 |
|
whartung |
and the game with REST is identifying resources |
| 20:59 |
|
arbelos |
my feeling is that a document database paradigm fits much more naturally into this picture than a RDBMS |
| 21:00 |
|
whartung |
document database vs rdbms has nothing to do with this discussion… :) |
| 21:00 |
|
whartung |
Resources Don't Care How They Are Persisted. Resource are a REPRESENTATION of the "real resource", they are not the resource itself. |
| 21:00 |
|
arbelos |
no but with actual implementation |
| 21:01 |
|
whartung |
but that's after you've decided what you need at a resoure level. |
| 21:01 |
|
whartung |
A database is designed around it's queries, not the format of the data you plan to feed it. |
| 21:01 |
|
whartung |
different problem |
| 21:02 |
|
arbelos |
yes. i accept that :) so the trick is to separate the concerns and not think in terms of persisting data when designing the api |
| 21:02 |
|
whartung |
si |
| 21:03 |
|
whartung |
make a stab ignoring those details, let the implementations leak in to the abstractions later |
| 21:03 |
|
arbelos |
"leak into"? |
| 21:04 |
|
whartung |
just like you said |
| 21:05 |
|
whartung |
your resource represenations are an abstraction, and you just suggested "a document db is better", suggesting you were going to let the implementation of your resource abstraction "leak" and influence the back end. |
| 21:09 |
|
arbelos |
ah. ok. and another question. directory structure style should not be used or? E.g., if I have customers in a specific region, the resource is obviously customer and I have a parameter, say customers?region=1, but some apis use /regions/1/customers |
| 21:10 |
|
whartung |
well in the first one, a region isn't a named resource. |
| 21:10 |
|
arbelos |
hmm |
| 21:12 |
|
arbelos |
so /regions/1/customers is preferred if region is an actual resource, or? |
| 21:12 |
|
whartung |
yes, if region is to be treated as a named resource |
| 21:14 |
|
arbelos |
ok |
| 21:14 |
|
arbelos |
thanks |
| 21:14 |
|
whartung |
yw hope it helped |
| 21:29 |
|
arbelos |
I am thinking though, why is a return a PUT? It is not obvious that it shouldn't be a POST, or is it? |
| 21:30 |
|
whartung |
it should probably be a POST so you can assign it a name |
| 21:36 |
|
|
benzrf joined #rest |
| 21:36 |
|
|
benzrf left #rest |
| 21:36 |
|
arbelos |
the resource analogy feels a bit abstract with things like "stock adjustment". what you said before was to imagine a document required for someone to be able to carry out the actual task, or |
| 21:45 |
|
whartung |
yes... |
| 22:14 |
|
|
tieTYT2 joined #rest |
| 22:49 |
|
|
vanHoesel joined #rest |
| 22:52 |
|
|
shrink0r joined #rest |
| 22:52 |
|
|
co-arbelos joined #rest |
| 23:10 |
|
|
vanHoesel joined #rest |
| 23:43 |
|
|
tieTYT2 joined #rest |
| 23:51 |
|
|
vanHoesel joined #rest |
| 23:59 |
|
|
shrink0r joined #rest |
