Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make an API interface #13

Open
ryzokuken opened this issue Jun 6, 2017 · 9 comments
Open

Make an API interface #13

ryzokuken opened this issue Jun 6, 2017 · 9 comments

Comments

@ryzokuken
Copy link
Member

ryzokuken commented Jun 6, 2017

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
Copy link

@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
Copy link
Member Author

@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
Copy link
Member

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
Copy link
Member Author

@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
Copy link
Member Author

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
Copy link
Member

jywarren commented Jun 16, 2017 via email

@ryzokuken
Copy link
Member Author

@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
Copy link
Member

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

@jywarren
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants