Just looking again at the Angular front-end it reminded me that we need a way to retrieve a list of what Tag terms are available.

What I'd really love to see would be a way to access the data in a way that would enable 'predictive text' so if users started typing into a search box we could pull up suggestions.

It could just be that the front-end grabs a list of all tags then works with it directly but I don't know how efficient that would be if we end up with a very large number of tags.

What does the API currently do if you try to add a tag/verse relationship that already exists?
Does is just create duplicate data or does it do something else?

My suggestion is that it would effectively 'up-vote' that tag and give it greater visibility in query results but I don't know what the best way to manage that in the database would be.

The way I've looked at doing it in terms of database structure is to have one table for the actual tag terms and a separate linked one for 'tag events' - when a tag is attached to a verse, up-voted (even down-voted?).

At the moment is appears you can only query the actual tag value.
It would be very helpful to find all the tags connected to a verse reference (or even multiple verses).

As of now, a person could tag a verse like genesis 128:512. That is something that doesn't exist. Obviously, if the API tried to return such a verse, it will return No Content, 204.

We should do the following: (i) check when saving a tag to see if it is a relevant passage, and/or (ii) create a scrubbing process to scrub the DB of invalid references.

Note, (i) could be achieved by pinging the DBP API to try and return content for the reference. We wouldn't necessarily have to store all the valid references on our end.

We should push a baseline of tags into the DB to initially increase our tag coverage. For example we could push in this data: https://www.openbible.info/topics/

Build in API key functionality for POST requests. Possible option is to use the free tier of Stormpath for key management.

Return the generated UUID identifying the tag to the user when making a POST.

Currently, when no passages match a specific tag, the API returns HTTP 204 No Content. From a front-ender's perspective, this is somewhat counterintuitive and harder to handle. When no verses are found to match, the API should return an empty array, so extra front-end code does not have to be written to handle the case when none match. Take this theoretical JavaScript code, for example, which is written to handle the current scenario:

getData((response, error) => {
    if(response.statusCode === 200 && !error){
        for(let verse of response.verses){
            tellUser(verse.text);
        }
    }
    else if(response.statusCode === 204){
        tellUser("Sorry, but no verses were found for that tag");
    }
    else if(error){
        // Inspect and handle the error case here
    }
});

That's a lot of extra boilerplate code that doesn't have to be written, and it should really be lumped into the error object, but it's not by default. A cleaner way to do that would be to just write the code to iterate over an array, and the case when no verses are returned will handle itself, like this:

getData((response, error) => {
    if(!error){
        for(let verse in responses.verses){
            tellUser(verse.text);
        }
    }
    else{
        // Handle the error case
    }
});

That alone shaved off 3 lines of code and one conditional statement that might not be so obvious to newcomers.

On top of that, a lot of frameworks, such as the one I initially used to build the Slackbot, don't allow direct access to the status code of the response, thus making it impossible to effectively handle this case without crashing.

That being said, I don't think we should get rid of 204 No Content altogether. I think it would make the most sense to return an empty array in the case that there are no verses found, thus you can unconditionally check response.verses for all your results, but I think the API should return 204 No Content when it's asked about an invalid verse, like Book 5:17 or Genesis 578:3252. Thus, the 204 No Content response can signify where there will forever truly be no content, instead of content just hasn't been added yet

There are minimal tests at the moment. Need to get the coverage up to at least 85%+

Build in Rethink Auth key functionality along with associated config.

A user should be able to search for multiple tags at a time, and the API should be able to return an array of verses that only match multiple tags, and potentially another array of verses that match only one. Furthermore, the user should be able to tag a passage with multiple tags at once. I feel like the 2nd scenario will be more easily implemented than the first, but discussion can be had in this thread about how to implement the 1st.

Do you plan to capture the user who tagged the verse? Also can I return all the verses tagged by a specific user?

Use Case:
Users create different content (Sermons, Music, Videos, Papers) user would use BIBLE TAG API toolbox to tag their content.
Basic BIBLE API Tagging would be done by Bible [BOOK] [CHAPTER] [VERSE]

User would go to Google or search engine that has the BIBLE API plugin - search for content (Music), (Video), (Sermons), (Poems), (Papers) and be able to search for content based on the Tags.

Example:

User says show me all Videos that are tagged with the BIBLE TAG of [John] [3:16]
And it would list all videos that have that tag.
I am interested in your ideas on how this TAGGING system would work.

Return verses for multiple tags. That is, a user could request a verse relevant to both love and salvation.

Provide example docker commands, including restart always configuration so the API restarts automatically on CoreOS.