To the breaking of API, the answer is yes and no:

  - yes: it will introduce a new Abstract class that is the first level of the Interface HttpDataFactory as the factory will have to include a "static" member : the pattern
  - no : except that, no other change (even less than in the current example which is fully compatible with the prior API already)

So from a strict point of view, yes, there is potential break. The only way I see to not introduce this change is to replace the interface HttpDataFactory by the Abstract class directly (keeping the very same name), but then lead to a change of "implements" to "extends".

So far, I'm not so happy about this change (as you understand, I try to find the best way, taking all advices).
So to resume;

   1. The current proposition does not change the API, but lack of "control" for the programmer, since the method is then "all or nothing".
   2. The next proposition (abstract class) allows more flexibility but could lead to an API change (minor but still).
   3. The next-next proposition would be to "duplicate" the pattern in each and every "data", by constructor addition, but in fact will lead to the very same kind of API break, since each "data" will have to extend their own constructor to accept such a pattern, and if none specified (default current constructor), they will have to rely on the "static default pattern" (especially the "copy" operation), which could lead to 2 optional issues:
         - either the default pattern is different to the default one specified by the user in the factory, and then could lead to misbehaviour
         - either we introduce again the abstract class (proposition 2) to host the current pattern (whatever the one from the user if specified, or the default one) and then we came back to the API issue of (2) (and moreover no interest of solution 3).

I must admit that it is like the chicken and egg issue...