Ten years back I looked into drafting a RESTful API for a mature software server that didn't expose yet a public API. What I did was read Roy Fielding's thesis

Ten years back I looked into drafting a RESTful API for a mature software server that didn't expose yet a public API. What I did was read Roy Fielding's thesis then try to apply REST from first principles to our services, sketching out an API pattern that complied with the best-practices he outlined. It quickly became apparent that a couple of things were very weird: (1) trying to reimagine our very stateful application in a stateless way was a BIG change for "let's add an API" work (2) trying to make it so that the client could enter the API with no knowledge of the initial URI, and find every other possible interaction using links provided by API responses, was pretty ambitious In retrospect what I probably should have done was rounded up a dozen potential API developers and interviewed them about the problems they expected to need to solve using the feature, then designed something that met their needs, rather than trying to build to Fielding's spec just because the feature request said "please build a REST API" and that's what a REST API is.