I'm not particularly sure what do you mean and want to achieve. Putting ORES behind RESTBase without using storage (as a simple proxy) will not really free up any resourses on ORES side. Do you mean you want reads of pre-computed scores to not touch ORES at all?

If I understand this task correctly, it seems to be a duplicate of T107196: Set up revscoring entry points in RESTBase.

In T214874#4925938, @mobrovac wrote:

If I understand this task correctly, it seems to be a duplicate of T107196: Set up revscoring entry points in RESTBase.

Thanks for mentioning this, it does look like nearly the same concept. I'm not familiar enough with RESTBase to give an opinion about whether that would be the right level for integration, but it's certainly worth more exploration. We're considering architectural changes to ORES which make it even more compatible with this approach, namely generating the scores as a decoupled, stream-based process and serving the API from a static, disk-based cache like Cassandra.

In T214874#4924829, @Pchelolo wrote:

Do you mean you want reads of pre-computed scores to not touch ORES at all?

Yes, exactly that! It should be possible to migrate from on-demand scoring to a stream-based backend, by at first serving uncached requests using an internal API request to ORES, then later filling the cache with a complete set of scores for each wiki. Having a non-ORES frontend would give us more flexibility in managing this transition.