Add REST API, update command line scripts to use REST API #54
Comments
|
changed the description Poster: Craig Harman |
|
mentioned in merge request !128 Poster: Craig Harman |
|
MTurk has a full API. Do we want to copy parts of it? I haven't checked how extensive it is. Poster: Cash Costello |
|
I'd need to investigate further, but I suspect the answer is yes. It would be nice to be able to leverage third-party tools related to quality control. If we want to make it easy for other services (such as AT-AT) to submit Tasks to Turkle, I suspect a REST API will be important for buy in. But from my (current) perspective, #143 and #135 are higher near-term priorities. Poster: Craig Harman |
|
mentioned in issue #132 Poster: Cash Costello |
|
mentioned in issue #171 Poster: Thomas Lippincott |
|
charman ccostello Is there anything in-progress on this? If not, I'll create a branch and start playing with django-rest-framework integration. Poster: Thomas Lippincott |
|
lippincott discussion on Github about this: #32 To summarize:
In additional to sketching out the API, I want to minimize duplicated code. I don't want to reimplement batch creation for the API as separate from what happens when forms are submitted. Poster: Cash Costello |
|
ccostello Agreed w.r.t. duplicated code. In addition to task/project management focus of the official API, my interest in a REST API is driven by wanting a simple way to produce backups and manage users/groups without having to SSH into a machine and run cumbersome Docker commands. This would be a modestly nice thing for me, but an extremely useful thing for some other group (like the library) maintaining their own instance with a minimum of hackiness. It seems good enough to just move in the direction of official-API-compliance by only defining the same commands when they match in functionality, and meanwhile having new, useful commands for these things...? Poster: Thomas Lippincott |
|
When I did the review of the official MTurk API and how we do things, they were different enough that I came away convinced that we should just build out the API that fits our use cases. We are template compatible with MTurk but we're not really compatible in any other way. My API endpoints would be
I want to keep backups as database specific rather than supporting that through an API. If we need to provide detailed instructions and sample scripts, let's do that. Poster: Cash Costello |
|
Agreed w.r.t. endpoints. Not that I disagree necessarily, but why database-specific? It seems like a major advantage of Django's agnosticism is you can easily say "give me a snapshot of the whole system as a JSON blob" (and "here's a JSON blob, roll back the system", or, offline, "show me a diff of these two snapshots", etc). Poster: Thomas Lippincott |
|
Now that I'm looking at it, the official mturk API mostly covers my concerns (there's an endpoint to get an assignment, which includes answers). So, as long as it's possible to perform these smaller requests and in principle back up any user-provided answers, this is fine (and would never involve a serving a huge monolith). I know we're not necessarily going to replicate Amazon's API, but I'm guessing we'll at least have endpoints along the lines of get_projects(), get_hits(project_id), get_assignments(hit_id), get_assignment(assignment_id), and that's plenty of functionality. Poster: Thomas Lippincott |
|
mentioned in merge request !231 Poster: Craig Harman |
The current command line scripts scrape the HTML of the admin pages, and break when the formatting of these pages changes.
This seems to be one of the more popular REST frameworks for Django:
https://www.django-rest-framework.org
Poster: Craig Harman id: 154
The text was updated successfully, but these errors were encountered: