These are chat archives for cltk/cltk_api

Mar 2016
Imran Ahmed Manzoor
Mar 19 2016 00:19
I think we should replace the <string:corpus>, <string:author> and <string:work> strings in the REST endpoints with ID's for each of them (corpus ID, author ID, work ID). We should also make the API "discoverable"; i.e. allow users to query /lang/greek/corpus/ to get a list of Greek corpora.
An example response would be:
GET /lang/greek/corpus
      {"id": 0, "corpus": "perseus"},
      { ... },
Imran Ahmed Manzoor
Mar 19 2016 00:26
The ID's also need to remain consistent across API releases. We can maintain this ID mapping in an sqlite3 database bundled along with the REST API web application.
Luke Hollis
Mar 19 2016 02:00
Interesting idea, @Imran31--what functionality do you think an ID number would add beyond querying on a unique slug?
Also, can you describe a little bit more about what you're thinking about with making the API more discoverable? Here's an example implementation that we're using with the frontend:
Imran Ahmed Manzoor
Mar 19 2016 11:31

The ID numbers would keep the URLs short, so we wouldn't need to worry about author/corpus names being too long.

Keeping the API discoverable would help once the API is consumed by more than just the CLTK frontend. This way, even if I don't know the IDs for a certain corpus or author, I can programmatically query the API and get a list of ID-author or ID-corpus mappings.

Manvendra Singh
Mar 19 2016 12:04
SoundCloud's public API is a great example of ID based approach.
Luke Hollis
Mar 19 2016 13:05
Okay, cool--I think I'm not quite envisioning your changes @Imran31, but I'd like to know more about. Can you create an issue on the cltk_api repo with a detailed summary of what you'd like to change and how that increases the discoverability of the API?
Imran Ahmed Manzoor
Mar 19 2016 19:41