consider dropping /rating-proposals/forecasts/{ratings-provider} endpoint in interop

[caindy]

An alternate proposal for the semantics forecasts was that there was an area-wide /ratings-proposal/forecast that every Ratings Provider is PATCHing. I documented that here https://trolie.energy/articles/forecast-windows#on-time--202-accepted (prematurely):

As discussed in Submitting Forecast Ratings, the client must PATCH the overall Ratings Forecast of the Clearinghouse Provider with their own proposal.

What are the interop use cases for /rating-proposals/forecasts/{ratings-provider} as a top-level resource? I'll try to enumerate some possibility and indicate why I think they are invalid.

• Check on my proposal: This is classic "POST-redirect-GET" territory... a UI POSTs a forecast, gets a redirect to the newly created resource URL, and GETs it for display. On the other hand, our interop use cases are API driven and use the PATCH's 202 Accepted or any of the 4xx responses to decide what to do next. From an interop perspective, by the time the PATCH is issued, the client has its own identifier for it, and they would update its submission status locally.
• Were my ratings used as limits?: This is data in the limits snapshot with provenance (detailed) and doesn't really line up with the semantics of the submission being a /ratings-proposal. Why have this info accessible two ways?
• Authorization of proposals: We will have to do object-level authorization in any case.

[caindy]

If this is accepted, note that we should change ratings-proposal/forecasts (plural, per Ratings Provider) to ratings-proposal/forecast (singular, PATCHing the area-wide proposal).

[getorymckeag]

Agreed, drop it. This was an artifact of when I was thinking about the "interop" scope of TROLIE in a much broader way.

[catkins-miso]

Thanks, I'll get this done first thing tomorrow.