Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(allsrv): add v2 Server create API
Here we're leaning into a more structured API. This utilizes versioned URLs so that our endpoints can evolve in a meaningful way. We also make use of the [JSON-API spec](https://jsonapi.org/). This provides a common structure for our consumers. JSON-API is more opinionated than other API specs, but it has client libs that are widely available across most languages. We've chosen not to implement the entire spec, but enough to show off the core benefits of using a spec (not limited to JSON-API spec). The JSON-API spec is VERY structured (for better or worse), and would make this a [level 3 RMM](https://www.crummy.com/writing/speaking/2008-QCon/) compliant service, when the links/relationships are included. That can be incredibly powerful. As maintainers/developers we get the following from using an API Spec: * Standardized API shape, provides for strong abstractions * With a spec/standardization you can now remove the boilerplate altogether and potentially generate :allthetransportthings: with simple tooling * We eliminate some bike-shedding about API design. Kind of like `gofmt`, the API is no one's favorite, yet the API is everyone's favorite Consumers benefit in the following ways: * A surprised consumer is an unhappy consumer, following a Spec (even a bad one), helps inform consumers and becomes simpler over time to reason about. * Consumers may not require any SDK/client lib and can traverse the API on their own. This is part of the salespitch for RMM lvl 3/JSON-API, though I'm not in 100% agreement that is worth the effort. We've introduced a naive URI versioning scheme. There are a lot of ways to slice this bread. The simplest is arguably the URI versioning scheme, which is why we're using it here. However, there are a number of other options available as well. Versioning is a tough pill to swallow for most orgs. There are many strategies, and every strategy has 1000x opinions about why THIS IS THE WAY. Explore the links below yourself, determine what's important to your organization and go from there. Take note, there are many conflicting opinions in the resources above :hidethepain:. Another thing to take note of here is our use of middleware has increased to include some additional checks. In this case we have some additional checks, that all return the same response (via the API spec), and creates a one stop shop for these orthogonal concerns. For flavor, we've made use of generics to adhere to not only the JSON-API spec, but also the reduce the boilerplate in dealing with handlers. We'll expand on this in a bit. Next we'll take a look at making our tests more flexible so that we can extend our testcases without having to duplicate the entire test. Refs: [Intro to Versioning a Rest API](https://www.freecodecamp.org/news/how-to-version-a-rest-api/) Refs: [Versioning Rest Web API Best Practices - MSFT](https://learn.microsoft.com/en-us/azure/architecture/best-practices/api-design#versioning-a-restful-web-api) Refs: [API Design Cheat Sheet](https://github.com/RestCheatSheet/api-cheat-sheet#api-design-cheat-sheet)
- Loading branch information