Open ShadowPeo opened 2 months ago
You're correct in identifying that the API Disco ICT exposes is largely suited to support its own UI. Authoring a separate API to cover all of Disco ICT's functionality would be initially prohibitive. Perhaps we can start small, with a specific use-case, and make sure appropriate API's are available to meet those needs. Did you have an idea of a workflow you would like to support? Feel free @ShadowPeo to reach out directly if you'd rather the conversation continue privately.
Posting this for someone else on the team
In regards to this, my first thoughts for starting small would be providing ways to gather data. For example API endpoints to: Query a user and return all assigned devices and basic data (serial, asset tag, model, profile, batch, assigned date) Query a device and return assigned user, last network login/last seen Query a user and return open jobs, dates created, type, reference and their statuses (Open, Awaiting account payment, awaiting repairs etc) Query a job and return status all required components to be paid for
Including the ability to use an API key for authentication for new and existing endpoints (Such as /api/device/UpdateLocation and /api/device/LastNetworkLogonDate).
The next, more complex steps, would be methods to add data like creating or updating a job for a user.
To read data from Disco ICT, I'd recommend connecting directly to the SQL database. Read-only permission can be assigned to either a user, or a SQL account. It is true that changes to the SQL schema could change over time (years) although these have proven to be largely additive (which don't break anything sensible). The database is quite logically laid out. But definitely reach out if you need assistance locating some data.
From what we can see, the current API is limited when integrating with other software. Having a REST API would allow us to better integrate the system within our workflows