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

Add a proper API #232

Open
chriscool opened this issue Dec 22, 2017 · 9 comments
Open

Add a proper API #232

chriscool opened this issue Dec 22, 2017 · 9 comments

Comments

@chriscool
Copy link
Contributor

Commit 8ea2dc2 (Remove tastypie dependency, 2013-11-13) removed the api/v1 REST api, so there is no way anymore to create environments programmatically.

In #231 @tobami wrote that "a proper API would be very useful", so let's discuss how a proper API should look like.

First would it be ok to use the Django REST framework for this API?

@tobami
Copy link
Owner

tobami commented Dec 23, 2017

The DRF is certainly an excellent library for that, the only concern would be to add a non-trivial dependency. Any preference?

@chriscool
Copy link
Contributor Author

No preference, but I would like the framework and Codespeed to support OAuth2.

@tobami
Copy link
Owner

tobami commented Dec 25, 2017

Al-right, then let's use DRF. Let's get started with the spec.

@tobami
Copy link
Owner

tobami commented Dec 25, 2017

Auth:

  • Token Auth (for simplicity)
  • Oauth2

@tobami
Copy link
Owner

tobami commented Dec 25, 2017

Endpoints:

  • Environments

What other endpoints would you find useful to start with?

@chriscool
Copy link
Contributor Author

I don't think I would need another endpoint, because the "executables" and "benchmarks" are created automatically. But maybe there should be other endpoints at least for reading.

@tobami
Copy link
Owner

tobami commented Dec 28, 2017

Well, if we add a new endpoint to store results, it might not create all those automatically any more, so we would have to add them then.
Let me prototype this (or if you want to write a draft or do so yourself...)

@smarr
Copy link
Contributor

smarr commented Dec 31, 2017

Since @tobami asked for an opinion: What's the goal here, having an API to create the various things like environments, executables, and benchmarks?

In my usage, I rarely add an environment, so, that's not an issue have have been thinking about.
However, I have a strong preference for executables and benchmarks to be created automatically.
Especially for benchmarks, I add new ones from time to time, and it is great that I don't have to do anything specific when submitting data for them.

For the Are We Fast Yet? project, I am also somewhat relying on automatic executable creation. It's nice to be able to just add a new language, and not have to think about what codespeed is going to do, see: http://awfy-speed.stefan-marr.de/timeline/

So, I'd strongly advocate to keep creating things automatically, it's very very convenient. :)

@tobami
Copy link
Owner

tobami commented Dec 31, 2017

Yes, that's the goal, an API that exposes the "various things" so they can be created, read and modified.

We'll keep creation of benchmarks and so on automatic then. It makes sense to treat them like more structured tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants