Make an API interface

[ryzokuken]

Add an API interface to the list of interfaces of the bot. This interface acts as an endpoint that can be utilized by frontend applications (eg: a sandbox webapp on publiclab.github.io/plotsbot).

In its simplest form, the API could constitute of a single route that would accept a GET request with some request data in the form of a message and the bot would respond in the form of the response the bot would normally send on the chat interface, and an empty response body if the bot wouldn't respond to such a message on the chat interface.

For this task, we might require a backend routing library or even a full-blown backend web framework (feedback appreciated from @publiclab/soc) like Koa.

[david-days]

@ryzokuken , it's not a requirements, but if we write swagger-compliant (or wrapped) service APIs, then we'll be able to pull this into the overall developer interface that we're working on as Planning Issue #1449 of the plots2 code.

I'd be glad to help out on this. Here's some links for your consideration:

NodeJS Swagger Swagger UI, similar to the one being added to the plots2 code Tutorial

As I said, none of this is required, but just a thought on long-term unification and standardization. The most important thing is to get the work done--we can add/convert/modify later.

I'd be glad to help if you need anything in particular.

[ryzokuken]

@david-days This sounds great. I have no reasons not to make the API swagger compliant and would love to work with you on this.

[ananyo2012]

Sounds exciting! An web API for plotsbot. I will have a look a Koa. I know a bit about Express. But the look will be for something in which we can quickly integrate the API.

[ryzokuken]

@david-days According to what I found on the internet, Swagger is a tool for autogenerating APIs with sufficient documentation for YAML configuration files. For Node, it generates a new API project with the backend framework of your choice (Express, Hapi etc) with the given specifications. It also comes with an editor which makes writing APIs a breeze.

However, I feel like Swagger might not be the best option for plotsbot because I had been planning to write the API in the form of an interface for the bot, which would mimic the actions of any other interface (eg: IRC). I don't think writing an application with such specifications would be possible with Swagger. Also, now that we know that Swagger is just autogenerating an API written in say, Koajs; We can write the API for plotsbot in Koajs tailormade for our needs and then somehow find a way to make it compliant with Swagger.

Looking forward to discuss this with you.

[ryzokuken]

This seems to be the next best task for me to pick up.

@ananyo2012 looking forward to discuss with you about this tomorrow and start working on it.

[jywarren]

Hi, Ujjwal - which other interfaces are complete -- the console one and the chatbot one, right? Shall we build out a more complex behavior for the chatbot interface first?

On Fri, Jun 16, 2017 at 1:45 PM, Ujjwal Sharma notifications@github.com wrote:

This seems to be the next best task for me to pick up.

@ananyo2012 https://github.com/ananyo2012 looking forward to discuss with you about this tomorrow and start working on it.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/publiclab/plotsbot/issues/13#issuecomment-309090094, or mute the thread https://github.com/notifications/unsubscribe-auth/AABfJ-0vg4GZLJfFwaSFyhjYGXHnaYTOks5sEr8-gaJpZM4NxLWQ .

[ryzokuken]

@jywarren that definitely sounds good. I think we desperately need more feature issues. Let's talk today and draft up a small list of features we can work on next?

[ananyo2012]

Yes @ryzokuken is right. For now we should think of more feature issues than making a new interface

[jywarren]

Features meaning behaviors?

Let's get the behaviors into their own folder and standardize the way to add a new behavior accordingly, i.e.

1. add a new file to /behaviors/ following the format in the help behavior
2. add a new line to /behaviors.js (included into util.js?) requiring your new file
3. add a test for your new behavior, showing how it's supposed to work, following the example in /spec/help_spec.js (or equivalent)

Actually, i'll add this to the other issue: #39. Then we can build out lots of behaviors quickly and in a standard way