refactor: convert API to REST

[talentedmrjones]

GraphQL has proven to be more challenging in many respects, and so moving to a RESTful design can solve these issues.

Challenges with GraphQL

• Keeping business logic separate from the Graph resolvers is possible but makes a more expansive code base that is more difficult to understand and maintain
• Maintaining separation of concerns, for example keeping graphql.ID out of the model package, would require layers of transform that would further exacerbate the sprawling and maintainability issues
• Authorization is challenging because to gain the resource and action the query must be parsed and the graph tree traversed which pushes authorization checks throughout the resolvers. Furthermore it is sometimes necessary to securing individual fields apart from the query itself which is a greater lift than simply authorizing the endpoint as a whole like in REST.
• The N+1 issue where queries that include sub resources result in a query for the list and a query for each item in the list, which is further complicated by each additionally nested resource. This leads to many database queries which are difficult to optimize
• The inability to retrieve a list of fields that were queried for which could potentially help the previous issue

The article Why after 6 years Im over GraphQL explains these issues in great detail. While not every issue was directly faced, they were all apparent as potentials and likely would be faced had we continued with GraphQL.

Benefits of REST

REST is much more straightforward, being essentially a mapping of routes to handlers.

• Authorization is easier because most everything need (resource, action, and principal) is already available in the request thus it is only necessary to authorize the endpoint as a whole
• The code base is simpler and easier to understand
• HTTP status codes are now meaningful as opposed to GraphQL returning 200 for everything even on errors

closes #78
closes #79
closes #80
closes #81

[ATNoblis]

LGTM