-
Notifications
You must be signed in to change notification settings - Fork 28
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
Comments
@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 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. |
@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. |
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. |
@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. |
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. |
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 ***@***.***> 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
<#13 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABfJ-0vg4GZLJfFwaSFyhjYGXHnaYTOks5sEr8-gaJpZM4NxLWQ>
.
|
@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? |
Yes @ryzokuken is right. For now we should think of more feature issues than making a new interface |
Features meaning behaviors? Let's get the behaviors into their own folder and standardize the way to add a new behavior accordingly, i.e.
Actually, i'll add this to the other issue: #39. Then we can build out lots of behaviors quickly and in a standard way |
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.
The text was updated successfully, but these errors were encountered: