You're not actually executing a batch. You're just running its execute function. This would limit your class to the normal REST API governor limits. Instead, you should create two virtual classes:

Iterable mode

global virtual class BatchableObjectClass implements Database.Batchable<Object>, Database.Stateful {
    global virtual Iterable<Object> start(Database.BatchableContext bc) {
        return null;
    }
    global virtual void execute(Database.BatchableContext bc, Object[] items) {
    
    }
    global virtual void finish(Database.BatchableContext bc) {
    
    }
}

SObject mode

global virtual class BatchableSObjectClass implements Database.Batchable<SObject>, Database.Stateful {
    global virtual Database.QueryLocator start(Database.BatchableContext bc) {
        return null;
    }
    global virtual void execute(Database.BatchableContext bc, sObject[] items) {
    
    }
    global virtual void finish(Database.BatchableContext bc) {
    
    }
}

From here, your code has to change slightly to support this change:

@RestResource(urlMapping='/TWSSubmitApexClass/*')
global with sharing class TWSSubmitApexClass{
    @HttpGet
    global static void doGet() {
        RestRequest req = RestContext.request;
        RestResponse res = RestContext.response;
        String apexClass = req.requestURI.substring(req.requestURI.lastIndexOf('/')+1);
        Type t = Type.forName(apexClass);
        Object s = t.newInstance();
        if(s instanceOf BatchableSObjectClass) {
            Database.executeBatch((Database.Batchable<SObject>)s);
        }
        if(s instanceOf BatchableObjectClass) {
            Database.executeBatch((Database.Batchable<Object>)s);
        }
    }
}

This class handles normal "query type" projects and "iterable" type projects. The only downside is that your code will be required to cast generic objects and sobjects into concrete objects on the receiving end. This will only add a couple of lines of code, so it shouldn't be a big deal.

You're not actually executing a batch. You're just running its execute function. This would limit your class to the normal REST API governor limits. Instead, you should a virtual class:

global virtual class BatchableObjectClass implements Database.Batchable<Object>, Database.Stateful {
    global virtual Iterable<Object> start(Database.BatchableContext bc) {
        return null;
    }
    global virtual void execute(Database.BatchableContext bc, Object[] items) {
    
    }
    global virtual void finish(Database.BatchableContext bc) {
    
    }
}

From here, your code has to change slightly to support this change:

@RestResource(urlMapping='/TWSSubmitApexClass/*')
global with sharing class TWSSubmitApexClass{
    @HttpGet
    global static void doGet() {
        RestRequest req = RestContext.request;
        RestResponse res = RestContext.response;
        String apexClass = req.requestURI.substring(req.requestURI.lastIndexOf('/')+1);
        Type t = Type.forName(apexClass);
        Object s = t.newInstance();
        Database.executeBatch((Database.Batchable<Object>)s);
    }
}

This class handles normal "query type" projects and "iterable" type projects. The only downside is that your code will be required to cast generic objects and sobjects into concrete objects on the receiving end. This will only add a couple of lines of code, so it shouldn't be a big deal.

Note that for query types, you'll have to cast the query locator into an Iterable<Object> return type, and you'll have to cast the Object[] items into a SObject[] records variable to get at the SObject functions contained therein (you should also be able to cast directly to a known type, such as Account[], if you know the type beforehand).

Updates

• Updated code to reflect a single virtual class instead of two-- the latter appears redundant.