JanZerebecki added a comment.
make business logic that does not know or care about UI or web API
Where should this code live and how can one declare a dependency on it?TASK DETAILhttps://phabricator.wikimedia.org/T109836EMAIL
RobLa-WMF added a comment.
In T109836#2433074, @daniel wrote:
We can have this as an ArchCom session, but there was quite a strong consensus when we discussed this in Lyon
The problem that @Jdlrobson correctly identified is that the discussion wasn't captured in a way that we can clearly refer
daniel added a comment.
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
JanZerebecki added a comment.
My intent is in this task to only try if we can get by with only the existing
HTTP API functionality. If we find that some of the Wikibase uses can be
replaced and some can't be replaced with what the current HTTP API supports
then we replace the ones that makes
JeroenDeDauw added a comment.
Nobody talked about introducing a new API module.
And I did not say you did. I'm bringing up a concern I have about something not
explicitly talked about yet. Without doing that it'd rather hard to tell what
the intent is, or how people will interpret it.
TASK
JanZerebecki added a comment.
In https://phabricator.wikimedia.org/T109836#1561975, @JeroenDeDauw wrote:
While there might be places where this is a good pragmatic solution, doing
this everywhere would not be wise.
I don't understand. Do you have examples where it would not be wise? Why
JeroenDeDauw added a comment.
While there might be places where this is a good pragmatic solution, doing this
everywhere would not be wise. Don't forget about dependency injection. And
carefully consider if there is no simpler approach before introducing a new API
module meant for internal
