>From my experience this is mostly needed for operations/management API. Some examples: getStaus (i.e get the status/health from all endpoint) flashCache (make all endpoint flash their cache) setConfig (you get the point ...) more...
with regard to the fan-in question by Jonathan. Maybe return 207 (multi-status) https://httpstatuses.com/207 ? IMO, the most intuitive response would be a json array of all the endpoints responses, but I'm open for suggestions. Thanks, Amotz בתאריך יום א׳, 10 ביוני 2018 ב-14:23 מאת Baptiste <bed...@gmail.com >: > > > On Sun, Jun 10, 2018 at 12:36 PM, Jonathan Matthews < > cont...@jpluscplusm.com> wrote: > >> On 10 June 2018 at 08:44, amotz <amot...@gmail.com> wrote: >> > I found myself needing the options to do "fantout" for a call. Meaning >> > making 1 call to haproxy and have it pass that call to all of the >> endpoint >> > currently active. >> > I don't mind implementing this myself and push to code review Is this a >> > feature you would be interested in ? >> >> Hey Amotz, >> >> I'm merely an haproxy user (not a dev and nothing to do with the >> project from a feature/code/merging point of view), but I'd be >> interested in using this. >> >> I feel like an important part of it would be how you'd handle the >> merge of the different server responses. I.e. the fan-in part. >> >> I can see various merge strategies which would be useful in different >> situations. >> >> e.g. "Reply with *this* backend's response but totally ignore this >> other backend's response" could be useful for in a logging/audit >> scenario. >> >> "Merge the response bodies in this defined order" could be useful for >> structured data/responses being assembled. >> >> "Merge the response bodies in any order, so long as they gave an HTTP >> response code in the range of X-Y" could be useful for unstructured or >> self-contained data (e.g. a catalog API). >> >> "Merge these N distinct JSON documents into one properly formed JSON >> response" could be really handy, but would obviously move haproxy's >> job up the stack somewhat, and might well be an anti-feature! >> >> I could have used all the above strategies at various points in my career. >> >> I think all but the first strategy might well be harder to implement, >> as you'll have to cater for a situation where you've received a >> response but the admin's configured merging strategy dictates that you >> can't serve the response to the requestor yet. You'll have to find >> somewhere to cache entire individual response bodies for an amount of >> time. I don't have any insight into doing that - I can just see that >> it might be ... interesting :-) >> >> If Willy and the rest of the folks who'd have to support this in the >> future feel like this feature is worth it, please take this as an >> enthusiastic "yes please!" from a user! >> >> Jonathan >> >> > > Hi, > > what's the use case? > Is this API gateway kind of thing? > > Baptiste >
