Add new controllers to custom apismaster

[eduardocordova21]

This pull request introduces a new API controller for device operations and makes supporting changes to enable and register this controller in the openPDC application. The most significant update is the addition of the DeviceController, PhasorController and DevicePhasorController, which provides REST API endpoints for querying device information. Supporting changes include registering the new controller in the web application startup and introducing a constants class for string values used in the adapter layer.

New API Functionality

• Added a new DeviceController, DevicePhasorController and PhasorController classes in openPDC.Adapters that exposes several REST API endpoints for querying device data, such as retrieving all devices, querying by acronym, company, protocol, and enabled status. The controller includes logging and error handling for each endpoint.
• Introduced a new internal static class StringConstant in openPDC.Adapters.Constants to centralize string constants used throughout the adapter and controller code.

Application Startup and Registration

• Registered the new DeviceController, DevicePhasorController and PhasorController in the web API configuration within Startup.cs, ensuring its endpoints are available as part of the application's API surface.
• Updated and reorganized using statements in Startup.cs for clarity and to include necessary namespaces for the new controller and API functionality. [1] [2]

Code Quality and Maintenance

• Improved code comments and formatting in Startup.cs for better readability, especially around JSON serialization settings, CORS policy, and assembly loading. [1] [2] [3]
• Moved the static AuthenticationOptions property to the top of the Startup class for better organization. [1] [2]

[ritchiecarroll]

These new suggested controllers are an interesting addition, were you hoping to use these new controllers to support a new UI or similar function you are developing?

Right now, most of this functionality duplicates the available record I/O operations defined in the PhasorWebUI.PhasorHub, which is SignalR.Hub based, exposing record operations via JavaScript functions instead of a controller-based REST-API as your PR proposes.

Your PR code looks very clean and I have tested it -- everything seems to run OK. FYI, should we accept the PR, there may be a few minor suggestions we request related to code style, etc. just to match general openPDC coding patterns for ease of future maintenance. Additionally, we would likely want to migrate the controllers to a library in the Grid Solutions Framework so the controllers could be used in openPDC as well as openHistorian, both of which expose similar web service functionality. Even so, instantiating the controllers in the Startup.cs of both projects would still be needed to ensure controller was available as a loaded type before the web service started -- so, basically this would become three PR's, main code in GSF, then startup code in openPDC and openHistorian.

One thing to note is that since these controllers sit behind openPDC's security apparatus, access to the exposed controllers will be based on the authenticated openPDC user which makes access to the controllers secure. This is good, but this also means the REST web controller consumer tool or UI must be authenticated as an openPDC user in order to use the REST web service. This works naturally if the UI or tool consuming the controllers also sits behind the openPDC web service, with user logging into the openPDC web UI first, but it might be otherwise cumbersome if the controller consuming UI tool exists outside the openPDC web service, because: (1) the openPDC would need to be configured to allow CORS-based access to the consuming external application, and (2) use of the controllers would require an openPDC user to first authenticate the web service with a web browser -- OK for a UI, but not ideal for an automated tool. So, this is something to consider, and gets back to the main question, i.e., were you hoping to use these new controllers to support a new UI or other function?

Currently the controllers appear to be read-only so any controller consuming UI tool would be limited to viewing data only.

Allowing the addition of these controllers into the openPDC/openHistorian/GSF would need a defined purpose -- so let's further discuss the target use case you had in mind here.

Thanks!
Ritchie