So, I guess I don't mean to replace it, but maybe offer a REST option while keeping SOAP for legacy (since it doesn't really change that much). Web-focused languages (such as JavaScript/TypeScript) support SOAP but can be difficult to implement outside of a common library. SOAP adds a lot of overhead for simple requests and you must rely on a WSDL (again, RR API really doesn't change that much to matter).
After revisiting this question and seeing your question, while a REST API would be nice (since RR is modernizing things with the frontend already), my main pain point currently is the authentication workflow. When designing a web service that interacts with the data from the API, I must keep the user's password in memory with no recourse if the user refreshes (since storing it in a cookie or local storage would open my service up to many security attacks) and reask their credentials any time it is lost in memory (again, a page refresh or revisiting the app).
Something that relates to both desktop applications and web apps is storing the client's password on the machine so it has it when requesting data. An authentication token and refresh token would be more secure as it doesn't require the user to change their password when something is compromised. It also doesn't increase the user's fallout in a hack if the user reuses passwords across multiple sites (a token is only valid for services that accept it, which in this case would only be the RR API).
I didn't include what exactly I was asking in my original question, and I probably should have. With Yahoo Groups gone, there is no one place to ask developer related questions, so I figured the site refresh would be a good place to ask since RRDB v2.0 is already making use of a REST API at
https://www.radioreference.com/db/apis/ (see the below screenshot) and I would love to see that for developers.
View attachment 121659
View attachment 121658
