feat(service): add generic HTTP service #506
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Adding a generic HTTP service. This service tries to provide common functionalities that would be required by a Notify HTTP service while staying intuitive, lean but powerful.
The service mostly is a wrapper around the standard libraries
http
package and provides us with some QoL functions, while still following the libraries general practices.See here for a usage example.
Motivation and Context
As discussed with multiple other devs, we decided to initiate the move away from the heavy SDK dependency over to a leaner but more manual approach. To achieve this we have to implement the services through direct HTTP calls rather than the usage of 3rd-party SDKs.
Implicitly this means that we'd end up with a ton of different implementations and practices when it comes to HTTP communication in Go. To avoid or minimize that, we decided to provide the project with a generalized HTTP service. Additionally, this will help people connect to services with HTTP endpoints that are not (yet) officially supported by Notify.
How Has This Been Tested?
Wrote extensive tests using the
net/http/httptest
package. I chose thehttptest
package over our common practice as I like the idea of a full integration test for our most fundamental service better, than to mock it.The
httptest.Server
used will run on thelo
network interface and we'll thus test against "real" HTTP calls instead of intercepted or emulated ones.As more and more services will be reimplemented with a manual HTTP approach, it is likely that this is gonna become the projects new standard for service testing, too. It feels like the right step at this point in time.
Types of changes
Checklist: