Exactly, that’s how it should be done ideally to offload work from our developers to SDKs. 
Parts of the work on the networking layer can be reused, one component even completely. On the consensus side, the HTTP(S) feature requires quite a different integration for the reason of not being self-validating payloads as in the case of Bitcoin. I.e., consensus needs to agree on the response which requires gossiping and signing responses and providing a response to consensus only once it has reached a threshold of supporting replicas. This is more complex than the ingress-like handling we do for Bitcoin blocks.
The simple notification scenario would be captured well as part of the extension to allow for a Customizable quorum (“unsafe mode”) with reduced security. See the HTTP(S) topic on the forum (Enable canisters to make HTTP(S) requests) for ongoing discussions on this.
If you want true support of an external service for making state-changing POST requests with the envisioned model, the external service will need to be able to handle n requests (1 from each replica) intending to achieve the same and only execute it once. Or you put a proxy doing this in front. There are multiple options with different tradeoffs here for connecting a blockchain with a traditional service.