I guess it comes down to is this: if we're going to continue supporting old behavior, they should be accessible via the same old requests. *This removes the need for existing clients to be updated in the first place*. If we eventually want to delete the old code keeping the old behavior separated from the new will make it clear & explicit what's being dropped and what to use instead. For example, dropping formatversion=1 means clients need to use formatversion=2 (or whatever other supported versions).
Lastly, changing the default behavior to make things sane for new developers is, IMO, a bad trade-off because they'll eventually get tripped by us pulling the rug out from under their feet by *breaking backwards compatibility stable APIs*. Those sorts of changes should be reserved for experimental or even beta APIs. Continuing queries seems like a stable—and pervasive—part of the API.
On Thu, Jun 18, 2015 at 11:40 AM, Brad Jorsch (Anomie) < bjorsch@wikimedia.org> wrote:
On Thu, Jun 18, 2015 at 11:33 AM, MZMcBride z@mzmcbride.com wrote:
Brad Jorsch (Anomie) wrote:
On Thu, Jun 18, 2015 at 10:37 AM, Brian Gerstle <bgerstle@wikimedia.org
wrote:
- Current, "change the default" approach:
- All clients start receiving warnings as *extra payload data* (how does this even work for API's w/o a response payload?)
What module in api.php doesn't have a response payload?
action=opensearch
with format=json is the only example I can think of.
I would think any request to api.php using format=none would lack a response payload? However I'm not totally sure that I'm reading and using the term response payload in the same way that you two might be.
Haha, true. But if someone is using format=none, they're explicitly not caring to know if their request worked or not. ;)
-- Brad Jorsch (Anomie) Software Engineer Wikimedia Foundation _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l