| Time |
S |
Nick |
Message |
| 00:03 |
|
|
tbsf joined #rest |
| 00:39 |
|
|
Coldblackice joined #rest |
| 00:46 |
|
|
fuzzyhorns joined #rest |
| 01:47 |
|
|
fuzzyhorns joined #rest |
| 02:05 |
|
|
fuzzyhorns joined #rest |
| 02:46 |
|
|
dEPy joined #rest |
| 03:06 |
|
|
huckleberry78 joined #rest |
| 03:18 |
|
|
fuzzyhorns left #rest |
| 03:18 |
|
|
fuzzyhorns joined #rest |
| 03:18 |
|
fuzzyhorns |
hypermedia: ever useful for mobile? (like ios) |
| 03:36 |
|
|
Caelum joined #rest |
| 04:11 |
|
|
tbsf joined #rest |
| 05:12 |
|
|
fuzzyhorns joined #rest |
| 05:27 |
|
|
huckleberry78 joined #rest |
| 05:49 |
|
|
dEPy joined #rest |
| 06:02 |
|
|
dEPy joined #rest |
| 06:14 |
|
|
fuzzyhorns joined #rest |
| 06:16 |
|
|
fuzzyhorns joined #rest |
| 07:28 |
|
|
huckleberry78 joined #rest |
| 07:29 |
|
|
fuzzyhorns joined #rest |
| 08:16 |
|
|
_ollie joined #rest |
| 08:28 |
|
|
Macaveli joined #rest |
| 08:46 |
|
|
Wildblue joined #rest |
| 09:28 |
|
|
huckleberry78 joined #rest |
| 09:30 |
|
|
fuzzyhorns joined #rest |
| 09:56 |
|
|
interop_madness joined #rest |
| 10:05 |
|
|
Coldblackice joined #rest |
| 10:31 |
|
|
fuzzyhorns joined #rest |
| 10:45 |
|
|
fumanchu joined #rest |
| 10:54 |
|
|
fumanchu joined #rest |
| 11:29 |
|
|
huckleberry78 joined #rest |
| 11:32 |
|
|
fuzzyhorns joined #rest |
| 11:36 |
|
|
Macaveli joined #rest |
| 11:58 |
|
|
mezod joined #rest |
| 12:03 |
|
|
Macaveli joined #rest |
| 12:09 |
|
|
Macaveli joined #rest |
| 12:11 |
|
|
huckleberry78 joined #rest |
| 12:22 |
|
|
Macaveli joined #rest |
| 12:49 |
|
|
Andre-B joined #rest |
| 13:14 |
|
|
Macaveli joined #rest |
| 13:33 |
|
|
fuzzyhorns joined #rest |
| 14:05 |
|
|
eschmidbauer joined #rest |
| 14:18 |
|
|
tbsf joined #rest |
| 14:21 |
|
|
huckleberry78 joined #rest |
| 14:34 |
|
|
fuzzyhorns joined #rest |
| 14:58 |
|
|
huckleberry78 joined #rest |
| 15:04 |
|
|
huckleberry78 joined #rest |
| 15:16 |
|
|
fumanchu joined #rest |
| 15:23 |
|
|
huckleberry78 joined #rest |
| 15:27 |
|
|
eschmidbauer joined #rest |
| 15:28 |
|
|
quimrstorres joined #rest |
| 15:28 |
|
|
eschmidbauer left #rest |
| 15:35 |
|
|
fuzzyhorns joined #rest |
| 15:58 |
|
|
gigo1980 joined #rest |
| 16:23 |
|
|
huckleberry78 joined #rest |
| 16:36 |
|
|
fuzzyhorns joined #rest |
| 16:39 |
|
|
quimrstorres joined #rest |
| 16:44 |
|
|
tbsf joined #rest |
| 16:45 |
|
|
Macaveli joined #rest |
| 17:01 |
|
|
foist joined #rest |
| 17:01 |
|
|
gigo1980_ joined #rest |
| 17:02 |
|
foist |
Can someone please provide some clarity regarding the `Accept:` header parameter? http://stackoverflow.com/a/7853235/2437225 suggests that it can be used to provide a “lite" version of a resource. Raymond Hettinger replies in the comments that it’s not a good idea. |
| 17:04 |
|
foist |
In my case, I have a /foo resource. I would also like to be able to provide a summarized representation of the same resource. The difference between the full version and the summarized is that the summarized one would show certain numbers in aggregate (sums, avgs, etc.) while the full would list each record that makes up the aggregates. |
| 17:04 |
|
foist |
Is this a case for using the `Accept:` header, or should I provide a separate endpoint for /foo-summaries or something like that/ |
| 17:05 |
|
foist |
s/\//?/ |
| 17:11 |
|
|
gigo1980__ joined #rest |
| 17:20 |
|
fumanchu |
separate endpoint |
| 17:21 |
|
fumanchu |
Accept is for distinguishing between media-types (format) not content |
| 17:35 |
|
foist |
fumanchu: how about using a GET param for something like /foo?summarize=1 instead of a separate endpoint? |
| 17:36 |
|
fumanchu |
that's fine. from the protocol point of view, that's a separate resource because it's a different URL, even if the implementation uses the same handler code to process the 2 requests |
| 17:38 |
|
foist |
fumanchu: I have two collections of endpoints: dashboard and mobile. They work with mostly the same endpoints, but require slightly different representation in each case. Is that duality best maintained or consolidated? |
| 17:41 |
|
fumanchu |
in my experience, it's best to provide a coherent API, and design the browser-client to GET a slightly different set of URLs than the mobile-client does |
| 17:42 |
|
fumanchu |
(where it matters) |
| 17:42 |
|
fumanchu |
it depends on why and how they're different |
| 17:44 |
|
fumanchu |
if the mobile needs more summaries and the browser needs more detail, then separate URLs for each works much better than Vary or Accept |
| 17:48 |
|
fumanchu |
design the API for any client. design the client for any API. those principles make it easier for either to be adapted to future versions of themselves. |
| 17:52 |
|
|
gigo1980__ joined #rest |
| 18:07 |
|
foist |
fumanchu: I don’t quite get that last message. |
| 18:11 |
|
fumanchu |
it's easy to think of a webapp as something you make and then you're done. so it seems natural to make a browser app and a mobile app, and have a custom API for each. but if the apps are successful, they and the API will need to grow and change. |
| 18:12 |
|
fumanchu |
one of the goals of the REST style is to acknowledge that up front |
| 18:13 |
|
fumanchu |
if you think of "my browser app now" and "my browser app next year" they probably look very different, so much so that they're almost like different clients |
| 18:15 |
|
foist |
I thought resources should have endpoints that are client-agnostic. |
| 18:16 |
|
fumanchu |
in the sense that there might be lots of different clients that use it, yes |
| 18:19 |
|
fumanchu |
design your API to be coherent and efficient based on the _service_, not on what data a particular client or application of that service thinks it wants today |
| 18:23 |
|
fumanchu |
for example, at our startup I designed a collection resource with links to each entity. some front-end guy said "oh, that won't work for me, I need a slightly different representation for my UI", and made a custom endpoint aimed at that UI feature. They finally just ditched the custom endpoint and went back to the one I made three years ago, because it's more coherent with the rest of the API, which makes their UI code simpler and cleaner. |
| 18:24 |
|
|
mezod joined #rest |
| 18:25 |
|
foist |
I appreciate the detailed explanation, but when I read all this, all that basically gets through to me is “make it good and it will work well”. I guess it’s an abstract problem with no concrete answers and a lot of grey area. |
| 18:25 |
|
fumanchu |
true |
| 18:26 |
|
fumanchu |
I guess I'm trying to say part of "good" is "reusable" rather than customized for a particular client or application |
| 18:27 |
|
foist |
Which is an argument to - in my case - consolidate dashboard and mobile. |
| 18:27 |
|
fumanchu |
yes, that would almost certainly pay off in simplicity |
| 18:33 |
|
foist |
Thanks for the talk, fumanchu. |
| 18:37 |
|
fumanchu |
np. sorry if I rambled :) |
| 18:37 |
|
|
fuzzyhorns joined #rest |
| 18:38 |
|
foist |
Nope, not at all. Discussing nuances concisely is approaching impossibility. |
| 18:41 |
|
|
gigo1980__ joined #rest |
| 18:48 |
|
foist |
fumanchu: I’m working on a sync mechanism. I want to make sure my /foo resources are synced between two servers. One of the requirements is that once Server B receives the /foo record, it sends a confirmation to Server A with some checksum value. If the checksum value is correct, Server A marks the sync as complete for that record. |
| 18:49 |
|
foist |
Does it make sense to have /foos and then /successful-syncs or is there a better approach? |
| 19:12 |
|
|
quimrstorres joined #rest |
| 19:27 |
|
|
quimrsto_ joined #rest |
| 19:38 |
|
|
fuzzyhorns joined #rest |
| 19:43 |
|
|
gigo1980__ joined #rest |
| 20:12 |
|
|
Coldblackice joined #rest |
| 20:39 |
|
|
fuzzyhorns joined #rest |
| 21:29 |
|
|
gigo1980___ joined #rest |
| 21:30 |
|
|
gigo1980____ joined #rest |
| 21:33 |
|
|
gigo1980____ joined #rest |
| 21:40 |
|
|
fuzzyhorns joined #rest |
| 22:16 |
|
|
huckleberry78 joined #rest |
| 22:22 |
|
|
huckleberry78 joined #rest |
| 22:40 |
|
|
fuzzyhorns joined #rest |
| 22:50 |
|
|
Left_Turn joined #rest |
| 23:27 |
|
|
fuzzyhorns joined #rest |
