I wrote this in the epic, but repeating here as an iterative plan:

In T417668#11651078, @Mooeypoo wrote:

To make this more iterative, here's my suggestion for MVP/step-one:

• Refactor business logic out of the Handler and into a dedicated class (no need to make it a just service yet)
• Add PHP Unit tests to that class
• Make config variables for the hard-coded urls in there without changing the object structure

Profit.

Then iterate on this and see whether that standalone class should be a service (I instinctively feel that a service may be overkill here, but we can discuss options) or a class that allows some easier internal registry for us to be able to add/adjust fields and manage optional dependencies, etc.

It's *basically* what's written in this ticket as it is (I just added that comment as a bit of a summary to the epic) but I think it's also okay to not spend too much time for the MVP of this with service wirings or stuff like that. It can be more like the REST Helpers, and we can iterate on better architecture of it having some easier extension-to-extension dependency as step 2.

Change #1247619 had a related patch set uploaded (by Atieno; author: Atieno):

[mediawiki/extensions/WikimediaCustomizations@master] Attribution: Refactor the business logic out of the AttributionRestHandler

https://gerrit.wikimedia.org/r/1247619

Change #1247619 merged by jenkins-bot:

[mediawiki/extensions/WikimediaCustomizations@master] Attribution: Refactor the business logic out of the AttributionRestHandler

https://gerrit.wikimedia.org/r/1247619