FauxRequests to action API modules are an antipattern that should be avoided. Instead, the functionality should normally be exposed by some "business logic" class that is used by both the action API and by other code.
Full conversation is documented here:
Various projects use FauxRequests and various projects use PHP classes directly.
According to @daniel in that same task
We can have this as an ArchCom session, but there was quite a strong consensus when we discussed this in Lyon: don't use the Web API interface and FauxRequests for internal requests. Reasons:
- It's a "stringly typed" interface, it lacks type safety
- the encoding/decoding is a performance issue.
- it makes things very hard to test - it's an antithesis to the idea of injecting narrow, easy-to-mock interfaces.
Best practice IMHO: make business logic that does not know or care about UI or web API, write a thin layer of UI or API on top of it.
I'd like us to discuss this again and document the decision/reasoning on wiki and in wikitech.
- Is use of FauxRequest discouraged in Special pages?
- When should FauxRequest be used?
- Somewhere like https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker seems appropriate.
- https://www.mediawiki.org/wiki/Architecture_guidelines#Separation_of_concerns_.E2.80.94_UI_and_business_logic ?
- Audit of existing uses of https://github.com/search?q=org%3Awikimedia+FauxRequest&type=Code and open tasks recommending changes where needed pointing to documentation to increase shared understanding