Ah, I see. I think you could still apply the same logic as follows:

Create the implementation class such that it only has the stub methods and calls into other classes for the processing logic. Like creating a service to receive the messages and pass it on to the process for business logic, so too can you leave your stub classes rather simple and pass to another class (set of classes) for the processing logic.

If you've gotten up in the thousands of lines simply from bare bones stub classes, exposing another endpoint is likely the way to go, where there will be a decent separation point somewhere in your API. Same issues apply as before; if you have so many stub methods that you're hitting this many lines in your class, you've got so many stub methods in a single endpoint that future dev work will be a pain.

From the ISC documentation Intro to Creating REST Services, they have the following example stub class and show placing your processing logic in the stub method as below:

/// A sample API that uses a petstore as an example to demonstrate features in the swagger-2.0 specification<br/>
/// Business logic class defined by RESTSpec in petstore.spec<br/>
Class petstore.impl Extends %REST.Impl [ ProcedureBlock ]
{

/// If ExposeServerExceptions is true, then details of internal errors will be exposed.
Parameter ExposeServerExceptions = 0;

/// Returns all pets from the system that the user has access to<br/>
/// The method arguments hold values for:<br/>
///     tags, tags to filter by<br/>
///     limit, maximum number of results to return<br/>
ClassMethod findPets(tags As %ListOfDataTypes(ELEMENTTYPE="%String"), limit As %Integer) As %Stream.Object
{
    //(Place business logic here)
    //Do ..%SetStatusCode(<HTTP_status_code>)
    //Do ..%SetHeader(<name>,<value>)
    //Quit (Place response here) ; response may be a string, stream or dynamic object
}

...
}

Rather than placing all of the logic here in the implementation class, which works well for APIs with a typical number of resources, you could instead pass off the business logic to other function calls outside of the implementation class. That way you only need to check out and modify the implementation class if you're adding URI updates, and have the processing classes that can be updated without impacting the implementation class (i.e. separate your front end vs back end dev work into separate classes).

It's a bit difficult to standardize how one should create these class separations, as it's highly dependent on user/customer preference, change control methodology, dev teams, and API. If you wanted to share more about the number of resources and stub method count, even in a private message, I'd be happy to try and provide a more specific set of thoughts.