Separate Upload and Recalculation REST endpoints into dedicated resources

[stalep]

Problem

FolderResource currently handles folder CRUD, uploads, upload status, recalculation, and recalculation status. As more endpoints are added (upload status tracking in #205, future view management), the resource class grows and mixes different concerns.

Proposal

Split into dedicated resource classes following REST noun-based organization:

FolderResource      → /api/folder      (CRUD, structure, dashboard)
UploadResource      → /api/upload      (upload action, status, changes)
RecalculationResource → /api/recalculation (trigger, status polling)

Current endpoints and proposed mapping

Current path	Current resource	Proposed resource
GET /api/folder	FolderResource	FolderResource
POST /api/folder/{name}	FolderResource	FolderResource
DELETE /api/folder/{name}	FolderResource	FolderResource
GET /api/folder/dashboard	FolderResource	FolderResource
GET /api/folder/{name}/structure	FolderResource	FolderResource
GET /api/folder/{id}/labelValues	FolderResource	FolderResource
POST /api/folder/{name}/upload	FolderResource	UploadResource (POST /api/upload/{folderName})
GET /api/folder/upload/{id}/status	FolderResource	UploadResource (GET /api/upload/{id}/status)
POST /api/folder/{name}/recalculate	FolderResource	RecalculationResource (POST /api/recalculation/{folderName})
GET /api/folder/recalculation/{id}	FolderResource	RecalculationResource (GET /api/recalculation/{id})

Notes

• h5m is not in production, so path changes are acceptable
• The upload and recalculation actions could stay on FolderResource as aliases for backward compatibility during transition
• This is a pure refactoring — no behavior change

[willr3]

I agree our rest API needs to be reviewed and standardized but I don't agree with the proposed solution. I found a quick description of REST best practices (https://blog.postman.com/rest-api-best-practices/) but please share if you are referencing a different best practice document.

I see two parts to this issue:

1. Creating a separate Resource for the Upload and Recalculation.
   I think Upload and Recalculate are verbs (e.g. "uploaded data") and not nouns (e.g. "the upload" or "the recalculation") and as such should not be treated as entities for the API. I think the Upload and Recalculation processing should be merged into a ProcessingService and exposed with a ProcessingResource so that users can observe the progress of data processing. This will likely require a change to ProcessingTrackerEntity which currently handles node changes by creating a single entity that encompasses all uploaded data. I planned to evaluate creating a separate ProcessingTrackerEntity for each RootNode's value after PR fix Work recalculate concurrency with cascade and fix rd work #210 is merged.

2. Moving the API endpoint out from the api/folder path.
   From my perspective anything that cannot exist outside of a specific scope should be contained to that scope. If all of a users actions with processing are scoped to a folder then I think it makes sense for the API to exist under the api/folder path. If we expect to offer access to all processing or to be able to fetch a filtered list of current processing based on folder or value then a api/processing/ endpoint would make sense. I think it is also reasonable for both to exist at the same time. Accessing the processing for a folder with GET api/folder/${id}/processing or GET api/processing?folderId=${id} can both be valid at the same time.