API

[cachethq]

API

[vkbansal]

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

[jbrooksuk]

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

[vkbansal]

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

[jbrooksuk]

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]

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 [email protected] wrote:

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

—
Reply to this email directly or view it on GitHub.

[jbrooksuk]

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

[jbrooksuk]

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

[manavo]

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]

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]

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

[manavo]

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

[Ehesp]

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]

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]

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]

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