Class composition/design pattern for similar classes - Java classes [closed]

The problem I am working on:

I am writing black-box tests for a legacy service - with the aim of writing a modern equivalent that will behave in the same way as the legacy variant. I have documented all the calls that the legacy service receives and these are now collected in about 30 JSONs of similar structure. The idea is that I write the tests for each call into the service, document all the outputs and then have a test suit that tests the functionality of the service which could then be tested against the new, to be written, service.

I am working in Java.

What I have done so far:

I have a bunch of JSON files, some nested, that represent requests to the server. There is about 30 of them. They have about 50 odd fields each. Majority of the fields have the same name and differ by value only - they either have a value (String, long etc) (which would vary from file to file but I am planning to use constants for those) or are null. About 20% of fields differ from file to file.

I have written POJOs for all of these and I realised that a lot of these POJOs are almost the same with some minor differences - the differences arise in the cases where the same field has a null value in one JSON and a non-null value in another.

I am struggling to think of a design pattern to use to reduce the number of similar objects and be able to construct the relevant objects with required fields as required for each type of request.

So, what I have done for one of the classes is have it implement an interface with default methods that throw an exception and then I use a helper method that takes an interface and constructs an object using try/catch to account for those fields that are not present. This is only a partial solution (ie it does not account for fields that are present but are null). Additionally, I am not happy with the solution because:

1. it does not actually reduce the number of classes, it merely allows me to build an object using any class that implements an interface and make sure that it comes out as required
2. if I follow this approach and implement similar structure for all the classes, my test suit is going to be very slow - it is going to keep throwing exceptions while building the objects
3. the solution still does not account for null fields.

I do need the null fields to be present in the JSON request sent to the service as this is part of the functionality of the current service. IE:

{
   "field1":"some value",
   "field2": null
}

is part of the expected call.

What I am looking for:

I am sure that I am missing something very obvious in terms of composition or design pattern that could be helpful here - someone must have had a similar problem before and has found a way to efficiently deal with it. Any suggestions would be welcome.