Skip to content
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

Closed
5 of 6 tasks
jbrooksuk opened this issue Nov 19, 2014 · 15 comments
Closed
5 of 6 tasks

API #3

jbrooksuk opened this issue Nov 19, 2014 · 15 comments

Comments

@jbrooksuk
Copy link
Member

An API should be able to:

  • Create, modify and update components.
  • Create, modify and update incidents (also linking to components).
  • Support third-party applications which can update statuses and messages.
  • Return components & incidents.
  • Save who created/last modified components or incidents.
  • Metrics API (Metrics #25)
@jbrooksuk jbrooksuk modified the milestone: First Release Nov 24, 2014
@vkbansal
Copy link

This may sound silly but will this include read? Will be very helpful for #4

@jbrooksuk
Copy link
Member Author

Sorry @vkbansal I don't quite understand. What do you mean by "include read"?

@vkbansal
Copy link

Sorry if wasn't clear. I meant API for fetching data.

@jbrooksuk
Copy link
Member Author

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.

@jbrooksuk
Copy link
Member Author

Sorry I've just got you. Yes I've updated the original issue to reflect that.

Sent from my iPhone

On 24 Nov 2014, at 11:27, Vivek Kumar Bansal notifications@github.com wrote:

Sorry if wasn't clear. I meant API for fetching data.


Reply to this email directly or view it on GitHub.

@manavo manavo mentioned this issue Nov 24, 2014
@manavo manavo self-assigned this Nov 25, 2014
@jbrooksuk
Copy link
Member Author

@manavo quick thought: we should use the app.key (or something else) as a token for sending API requests that should be private.

@jbrooksuk
Copy link
Member Author

Also I've just linked the metrics API in the list here.

@manavo
Copy link
Contributor

manavo commented Nov 25, 2014

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.

@jbrooksuk
Copy link
Member Author

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.

@manavo
Copy link
Contributor

manavo commented Nov 27, 2014

@jbrooksuk can't remember, is the services table for this? Or is the services table for HipChat, Slack, etc?

@manavo
Copy link
Contributor

manavo commented Nov 27, 2014

What kind of services are we expecting to send updates? Things like Pingdom? NewRelic?

@Ehesp
Copy link
Contributor

Ehesp commented Nov 27, 2014

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.

@manavo
Copy link
Contributor

manavo commented Nov 27, 2014

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?

@jbrooksuk
Copy link
Member Author

services is used to send to third parties. At the moment we don't have a way for third-parties to send to us though.

See #36 for the list of services we can integrate with.

@jbrooksuk
Copy link
Member Author

If the only thing in this list left is the third-parties we should close it in favour of #36.

MathisG-Recia pushed a commit to MathisG-Recia/Cachet that referenced this issue Apr 13, 2021
Update dependancies to latest patch versions + swapped discontinued
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants