| Time |
S |
Nick |
Message |
| 00:33 |
|
|
plm joined #rest |
| 00:44 |
|
|
fuzzyhorns joined #rest |
| 00:45 |
|
|
fuzzyhorns joined #rest |
| 05:49 |
|
|
wsieroci joined #rest |
| 06:13 |
|
|
_ollie joined #rest |
| 07:35 |
|
|
Coldblackice joined #rest |
| 07:38 |
|
|
Tomatosoup- joined #rest |
| 07:41 |
|
|
xsse joined #rest |
| 08:06 |
|
|
fuzzyhorns joined #rest |
| 08:27 |
|
|
wsieroci joined #rest |
| 08:36 |
|
|
interop_madness joined #rest |
| 08:36 |
|
|
xsse left #rest |
| 09:07 |
|
|
Macaveli joined #rest |
| 09:07 |
|
|
fuzzyhorns joined #rest |
| 09:46 |
|
|
sp1rs joined #rest |
| 09:57 |
|
|
sp1rs joined #rest |
| 10:08 |
|
|
fuzzyhorns joined #rest |
| 11:08 |
|
|
fuzzyhorns joined #rest |
| 11:20 |
|
|
sp1rs joined #rest |
| 11:42 |
|
|
sp1rs joined #rest |
| 11:50 |
|
|
sp1rs joined #rest |
| 12:07 |
|
|
tonyacunar joined #rest |
| 13:10 |
|
|
fuzzyhorns joined #rest |
| 13:21 |
|
|
Haudegen joined #rest |
| 13:29 |
|
|
Haudegen_ joined #rest |
| 13:30 |
|
|
fuzzyhorns joined #rest |
| 13:41 |
|
|
tbsf joined #rest |
| 13:54 |
|
|
itscaleb joined #rest |
| 14:27 |
|
|
ShekharReddy joined #rest |
| 14:57 |
|
|
sp1rs joined #rest |
| 16:35 |
|
|
tbsf joined #rest |
| 17:17 |
|
|
Coldblackice joined #rest |
| 18:30 |
|
|
jc3` joined #rest |
| 18:39 |
|
jc3` |
hi all. so ive tried to absorb a bunch of material on this and we're arguing back and forth internally: is it generally better to keep API endpoints modeled after their models/relations as close as possible where clients may have to make an extra HTTP req or two to get everything, or is it really that much more advantageous for clients to try to deliver everything via 1 endpoint in an m:n relationship, doing JOINs, post-processing, etc? |
| 18:41 |
|
whartung |
Well, the blanket guideline is "the internal data model is not the API" |
| 18:41 |
|
whartung |
REST works better with coarse resources. |
| 18:41 |
|
whartung |
not fine grained, chatty interfaces |
| 18:42 |
|
|
fuzzyhorns joined #rest |
| 18:42 |
|
whartung |
you should "GET /order/123" not "GET /order/123" followed by "GET /orderlineitems/123" |
| 18:43 |
|
jc3` |
hmmm that makes sense |
| 18:43 |
|
jc3` |
so its not a good idea to have an endpoint for a m:n relation then, having to query that to get ids and then query the resource for full info on those objects? |
| 18:43 |
|
jc3` |
generally speaking |
| 18:44 |
|
whartung |
I mean, it's all a balance right? That's ceratinly doable, and you'd probably want to do that if the resources are really enormous, but generally, the N+1 problem is exacerabated in REST API because connections are expensive |
| 18:47 |
|
jc3` |
true. so to get a list of topics, and then see a list of providers based on the topics chosen, GET /topics, then GET /topics_providers?topic_ids=1,8, then GET /providers?ids=10,20 is overkill huh. best to just GET /topics and then GET /providers?topic_ids=1,8 and mask the relational endpoint from the client |
| 21:26 |
|
|
sp1rs joined #rest |
| 21:57 |
|
|
tbsf joined #rest |
| 22:25 |
|
|
tbsf joined #rest |
| 22:54 |
|
|
tbsf joined #rest |
| 22:56 |
|
|
tbsf joined #rest |
