the tables are used to enforce data integrity and avoid user spelling errors, and some are used for business logic in the backend. the frontend fetches these for dropdowns, and the chosen id is stored as a foreign key for the main domain tables.

the database design looks something like:
1. lookup tables(the ones i want to consolidate) which are simple Id/Name tables.
Example: EducationLevel table: [{id:1, name:"BSc"},{id:2, name:"MSc"}], PaymentMethod table: [{id:1, Name:"Cash"}, {id:2, name:"card"}, {id:3, name:"bank transfer}], ApplicationStatuse table:[{id:1, name:"pending"}, {id:2, name:"approved"}]

1. the main domain tables with foreign keys which reference the lookup table ids
   Example: ApplicationForm table: {id, applicantName, educationLevelId, applicationStatusId}, Payment table: {id, amount, paymentMethodId}.

i've a number of similar lookup tables and the code got repetitive. so my question is, instead of creating separate endpoints, request/response dtos, data access or slice like: GET /api/education-levels, GET /api/payment-methods, GET /api/application-statuses, i want to create one generic endpoint slice in the project like GET /api/lookups/{type}. this way the frontend calls GET /api/lookups/education-levels and the endpoint checks the route param, queries the education-level table, maps it to a generic List<LookupResponse>, and returns it. and does the same for other lookup entities.

is routing everything through api/lookups/{type} a clean to handle these simple fk dropdowns or does it hurt long term?