codespeed
codespeed copied to clipboard
tobami
Add a proper API
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 https://github.com/tobami/codespeed/pull/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?
The DRF is certainly an excellent library for that, the only concern would be to add a non-trivial dependency. Any preference?
No preference, but I would like the framework and Codespeed to support OAuth2.
Endpoints:
- Environments
What other endpoints would you find useful to start with?
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.
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...)
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. :)
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.