What you're describing you're building might be more complicated then the problems I faced.
For apprise, I focused on what was common across all notification services: all of them had a body,
most have a title, and some allow you to attach images. Anything outside of these 3 fields then became very specific to that one (notification) service. The sacrifice made is that if you want in-depth functionality of a specific service with rich features, you won't achieve it with apprise. It can however accomodate some additional attributes via arguments... For example with email you can define the smtp server, from address, etc., but that wouldn't be applicable to say Twitter.
I know I'm drifting from your question, but with respect to what was said:
- enforce your own specification as you're right, you'll find everyone solves great problems differently.
- use inheritance. Base classes make life soo much easier.
- decide what is common or what you want to make common across your API endpoints and stick with that. Like the body, title, image issue I resorted too. Maybe you want to assume you'll always need a user and password too. Prepare to support tokens and open ids out of the gate in your base class
- don't try to extend on one endpoint too much regardless of how much feature rich functionality it offers. Focus on getting them all endpoints working using the standards you come up with. This will help you achieve your goal. Build onto it after.
- unit tests! They're a pain to learn, but you won't regret knowing your code remains stable!
As per monitoring, I presume you're running a web service at the end of the day. So there are many great monitoring solutions out there that can check your servers availability constantly. Nagios (or forks of it) for example can email you when your service gets disrupted allowing you to take action right away. Heck, Nagios+apprise and you can get a text message. There are lots of more modern monitoring tools as well that can do all this for you.
Sorry for the wordy reply, I hope I answered your questions!
For apprise, I focused on what was common across all notification services: all of them had a body, most have a title, and some allow you to attach images. Anything outside of these 3 fields then became very specific to that one (notification) service. The sacrifice made is that if you want in-depth functionality of a specific service with rich features, you won't achieve it with apprise. It can however accomodate some additional attributes via arguments... For example with email you can define the smtp server, from address, etc., but that wouldn't be applicable to say Twitter.
I know I'm drifting from your question, but with respect to what was said: - enforce your own specification as you're right, you'll find everyone solves great problems differently. - use inheritance. Base classes make life soo much easier. - decide what is common or what you want to make common across your API endpoints and stick with that. Like the body, title, image issue I resorted too. Maybe you want to assume you'll always need a user and password too. Prepare to support tokens and open ids out of the gate in your base class - don't try to extend on one endpoint too much regardless of how much feature rich functionality it offers. Focus on getting them all endpoints working using the standards you come up with. This will help you achieve your goal. Build onto it after. - unit tests! They're a pain to learn, but you won't regret knowing your code remains stable!
As per monitoring, I presume you're running a web service at the end of the day. So there are many great monitoring solutions out there that can check your servers availability constantly. Nagios (or forks of it) for example can email you when your service gets disrupted allowing you to take action right away. Heck, Nagios+apprise and you can get a text message. There are lots of more modern monitoring tools as well that can do all this for you.
Sorry for the wordy reply, I hope I answered your questions!
Good luck