These are chat archives for cltk/cltk_api

19th
Mar 2016
Imran Ahmed Manzoor
@Imran31
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
@Imran31
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
@lukehollis
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: https://github.com/cltk/cltk_frontend/blob/master/server/text-server-sync.js
Imran Ahmed Manzoor
@Imran31
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
@manu-chroma
Mar 19 2016 12:04
SoundCloud's public API is a great example of ID based approach.
Luke Hollis
@lukehollis
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
@Imran31
Mar 19 2016 19:41
Sure!