-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API #3
Comments
This may sound silly but will this include read? Will be very helpful for #4 |
Sorry @vkbansal I don't quite understand. What do you mean by "include read"? |
Sorry if wasn't clear. I meant API for fetching data. |
I see, the API will be able to return a JSON feed of incidents and components. This will allow third-parties to use this data too. |
Sorry I've just got you. Yes I've updated the original issue to reflect that. Sent from my iPhone
|
@manavo quick thought: we should use the |
Also I've just linked the metrics API in the list here. |
Yep, still debating how authentication should best work. The dingo/api package has an easy way to do basic auth, which uses email/password. But ideally, we should have an API key per user (to not end up with passwords stored elsewhere). For integrations where we'd be receiving metrics, there should be a separate secret key used for those, since it's more of a webhook type implementation, not a per user-authenticated call. |
Basic Auth solves most of the problem for us I guess. Things like third-party integration would need a secret key "per-party" though I guess. We could easily generate them. |
@jbrooksuk can't remember, is the services table for this? Or is the services table for HipChat, Slack, etc? |
What kind of services are we expecting to send updates? Things like Pingdom? NewRelic? |
I think the services table was to send updates on status'. Say, you could have a HipChat service, which can be enabled/disabled. But the services table holds the data to be able to send via Hipchat. |
Thanks @Ehesp, that's what I thought as well. So we'd need a new table for integrations updating the status of systems. We probably should put a list together for what integrations we'll support first? |
See #36 for the list of services we can integrate with. |
If the only thing in this list left is the third-parties we should close it in favour of #36. |
Update dependancies to latest patch versions + swapped discontinued
An API should be able to:
The text was updated successfully, but these errors were encountered: