Last modified: 2011-09-14 23:53:55 UTC
We added an API method to delete Upload Campaigns just to accomplish certain functionality in a POST request -- this seems like a bad reason to have an API method. Before people rely on this we should withdraw the API method.
IMO the best way to go these days is to design everything to use the API, and only add Special: page POST handling when needed for compatibility with non-JavaScript browsers and traditional form submission. This gives the greatest flexibility for the frontend UI to act in a modern fashion and allows for alternate UIs and bot-based activity to proceed if/as needed.
I agree with you that an API-like system is best for frontend design, but my concern is that actual API methods are guarantees to 3rd parties. Is there any way we can mark API methods as "internal", or otherwise not to be relied on?
Per kitchen discussion, we're provisionally agreeing to mark the API method as 'provisional' or otherwise 'not fully stable' in its documentation that appears in API help. Cleaning it up further and making the add/edit available through API as well in future would be nice at some point, but we don't have as much hurry as long as what's there is marked as incomplete so people know not to rely on it. We should also consider adding an explicit 'stability level' marker in the API help?
Resolving this bug as invalid... we can solve the issue with documentation for now, and that is fixed in r97121
