Refactor API to follow REST conventions

[johndeange]

Goals

• Endpoints should not have /endpoint/1/blah
  This should follow the following ruleset:

Should an endpoint exist

• Does it perform business logic checks?

• Does it perform a complex calculation?

• Is that resource used in more than 2 places in the frontend?

• Is it NOT only for rendering data cleaner (reducing the need for additional endpoint calls)?

• Responses should return ids or urls

[tdonaworth]

This is specifically referring to Resource Nesting - and doing it efficiently; There's no hard rule that says it has to be limited to one level, but that is the "preferred" path.
👍

[tdonaworth]

Examples:
1 /agreements/{id}/history returns the Agreement History records
Instead create
2 /agreement-history/{id} <-- Preferred based on AuthZ (for our discussion, this is considered BL) - until deemed otherwise.
3 /history?agreement_id={id} <-- could still be used, but preference would be as a redirect, or only for raw data consumption.

/portfolios/{id}/calcFunding --> /portfolio-funding/{id} <-- this one lives as a result of business-logic calculations
/portfolios/{id}/cans/ --> /cans?portfolio_id={id} <-- this one is a query filter

/bli-table-view?bli_id={id} BLI Summary Resource

Should an endpoint exist

• Does it perform business logic checks?
• Does it perform a complex calculation?
• Is that resource used in more than 2 places in the frontend?
• Is it NOT only for rendering data cleaner (reducing the need for additional endpoint calls)?

[tdonaworth]

Responses should return ids or urls

• For now continue to use ids, but if future support for uri is needed, no objections.