I would like to create my own web chatbot and i like to integrate my app with wit.ai for natural language classification.I need to know how to integrate wit.ai service(through api call) with my application(any language in backend).i am using C# in front end.I have gone through the integration part Which posted in wit.ai website.But i don't know how to connect it .Could anyone send me a integration details little briefly
I think the short answer is its similar to how you would call any other APIs from your application server components. Wit exposes multiple APIs like message, speech and converse which you can call by passing the Authorization token and other payloads and make use of the API response in your application.
You can use message API if you are only interested in extracting
intent and other atributes of the sententense
Use speech for building voice based application and
Converse if you want to build a little more smarter app. Currently you can only pass text for converse APIs.Hoping they will introduce voice option for this soon.
Now to make things simpler, they have also provided SDKs in various languages like node-wit, pywit etc. So if you want to build your server side logic using on nodejs or python you can use these SDKs. The advantage is that you dont have to manage raw APIs calls and instead it is all managed by SDK. Also, other big advantage is that you can make use of runActions method which encapsulates converse API and make things simpler. If you want to build in nodejs then the messenger example is a good starting point. You can borrow all this logic/concept in your app and replace FB related calls etc with your custom bot. For Python you can look at the below link
https://github.com/wit-ai/pywit/pull/55
Also, you can explore the options like using other frameworks like botkit if you plan to integrate wit with other chatbots like FB messenger or slackbot as these frameworks provide more flexibility and ability to easily switch to different chatbots in future. But they don't seem to properly support the converse API of wit.
You are specifically looking for integration details. Since you are using c# for frontend app, natuarally the best option would be to use c# for backend as well. In which case you will be left with directly calling wit APIs from your backend as I think there are no SDKs in c#. If you want to make use of SDK in node or python etc then you will have to build a rest based backend (for example) which can be invoked from your c# application. I am currently working on a nodejs app and integrating it with wit using node-wit. I can share some code once its ready but i dont know when I will be able to finish it. For bootstrapping my application I have used this node application. If you have some understanding of node then you can look at the /server/controllers logic. Similar to this application I have built a witController which uses runAction to interact with wit and I am calling this from front-end when user submits a message to your bot. The biggest challenge in runAction is to figure-out a way to send back the wit response to your front-end and get follow up response from user. Wit sends the response in Send method as you can see in the node-wit's messanger example.
Hope this helps!
Related
I don't know about testing but I would like to have a clear picture on how is API testing different from other testing methods.
API testing will not include UI as regular testing have
API testing requires basic networking knowledge such as what is the use of GET, POST, PUT, etc commands used.
API testing includes having knowledge of how various html elements work. For example, If I press a button, what will be the next function call. We need to know how 'button' element works
In API only API functions are tested, but in regular testing all the elements are tested
There are different tools used in API testing. POSTMAN is one of them
In API Testing we test Backend functionality while in Regular testing we check UI + Functional testing.
API Testing is helpful in testing Core Functionality.It helps us to reduce the risks.
Steps to Test API Manually:-
To use API manually, we can use browser based REST API plugins.
a)Install POSTMAN(Chrome) / REST(Firefox) plugin
b)Enter the API URL
c)Select the REST method
d)Select content-Header
e)Enter Request JSON (POST)
f)Click on send
g)It will return output response
Steps to start API Automation using REST
in general API testing is made for not doing many similar actions, when we can easily measure the result.
For example if you app button is not on the right place, it is hard to measure using code.
Another example is when you write a library for collections you can say just once:
CheckIntersect method:
result = mylibrary.getIntersection([1,2,3,4], [3,4,5,6])
if result != [3,4]
postTestError("CheckIntersect [1,2,3,4], [3,4,5,6]" + result.ToString() )
In this case you can easily measure the result, and not have a fear of you can't even find the problem in code.
I would like differentiate API vs. Other Testing instead looking into technical details.
API: Testing point of view the API is so important because, we can prepare independent test cases that are separate files. This makes our test approach relatively simple.
For better understanding, "Web API is typically done as HTTP/REST, nothing is defined, output can be eg. JSON/XML, input can be XML/JSON/or plain data. There are no standards for anything => no automatic calling and discovery."
API is a simple interface using HTTP protocol.
Other Testing:
Other testing like GUI, Regression, Unit, etc. Testing is absolutely essential for any application has to be in user friendly. The end user should be comfortable while using all the components should also perform their functionality with utmost clarity. Different Functional and GUI Testing can refer to just ensuring that the look and feel and Functional usability of the application is acceptable to the user.
Conclusion:
API can be:
Developed by one company, used by another company, and hosted by a third company Such involvement of several companies is a business cases for independent testing of API.
Example: Weather information API Developed and Tested by One & Accessed by many.
General Testing is testing each and every feature of the application from UI like web or mobile .
But,
API Testing is to verify the JSON Request to Server and Response from the Server .
If the application is using API all the content and Features based on the API Response from the Server .
For Example In FB app Profile screen, if the name is wrong ,
you can check from UI that general Testing, The same thing you can
Check it from API Response from the server , like below.
{"name":"Dharma","friends":450}
I am new to web dev but I have managed to build my site using GWT and GAE. I use RequestFactory for client-server communications.
Now, someone wants to make mobile applications that use my backend.
I have found that RequestFactory works very well with Android. But I am somehow afraid it will not work with other "not-google" front ends (iOS for instance).
So my question is, can I make an API based on my RequestFactory backend (servlet) that can be used by any client? Any initial pointers as to how to implement it would be appreciated.
I guess technically it would be possible. However, if you want to create an api anyone can use, you probably want an api were you specify both how to communicate with the api and the content send/received by the api. With RequestFactory both the how and what is shielded by RequestFactory. So if someone wants to communicate with your api and can't use the RequestFactory code in the project, the how and what of RequestFactory must be reverse engineered, and could change anytime because it's not guaranteed. Not the most elegant way to go forward.
A better approach is define an open api were you specify the how and what. For example with
and apu based on REST (the how), communicating JSON data, and to specify the content format (the what). An example of such an api is the twitter api.
For your own project you could build on your api also, for example by using RestyGWT. Then you don't have to maintain both the code for the RequestFactory interface and REST interface. For other platforms there are probably several libraries available to make developing against a REST interface easy.
Rest confuses me sometimes. I know that it involves creating an API layer over your data and then you make calls to that data through the API. The best way I think of Rest is that the actual Twitter website interfaces with the data-layer through API calls.
That made me wonder then: Is a backend-service like Parse also a Rest API to your data?
What might be the difference between Parse and say, building your own Rest API like this guy did: http://coenraets.org/blog/2012/10/nodecellar-sample-application-with-backbone-js-twitter-bootstrap-node-js-express-and-mongodb/ (he's getting some solid google rankings for his API tutorials).
A simple yes/no might answer the question, but providing details will really be appreciated.
I look forward to the answers.
Parse is built around a restful API just like most, if not all, other mBaaS out there.
A RESTful Api isn't just CRUD operations though nor is it the same thing as Parse. Parse is a company that provides a remote backend to developers using a RESTful api.
RESTful api !== BaaS
I have dealt with about 5 mBaaS and Parse isn't really one of them, but I've glanced at their API reference for JS and I think they use mongodb clusters. An mBaaS usually provides the developer the ability to have cloud storage, push notifications, server side code, easier social media integration, and mobile analytics. So it's not just any backend. Although there are some mBaaS, like Urban Airship, that only supply push notifications to developers.
A RESTful api at it's core usually has some key functions that are centered/wrapped around an httpRequest
They usually use "GET", "POST", "DELETE", and "PUT" to make all calls. Some allow the implementation of rpc for custom server logic. An mBaaS takes a lot of work to implement right and well. You can't build Parse in a Day. It takes a lot of planning and such. The differences between Parse and that guy in link are in the implementation, range of features, and purpose in general(the audience).
To better understand REST maybe look here you can also read the HTTP spec if you are feeling adventurous.
I have 2 different Rails application and I want these apps to send and receive information via an API. What is the correct way to do this?
I was trying to use this resource but I don't quite understand it: http://api.rubyonrails.org/
(I am not sure how to make the call for the different methods. Some methods show an URL which I guess I wouldn't have too much problem implementing, but what if the application is within the same server, what would be the correct way to call a corresponding API method.)
Is there a recommended beginners resource out there?
Thanks.
api.rubyonrails.org is Ruby on Rails documentation, so this is API of RoR. What you want is external HTTP, probably REST and probably JSON API.
There are many resources on building REST API's. In general you have to prepare some endpoints that application can send request to and handle responses.
Take a look i.e. on railscast about using active model serializers. This would be the part where you give other application endpoints to get or change data.
Normally you would stop here because in most cases you set API for other applications (like mobile or javascript applications). But in your case you will need something to send requests. There are many gems that allow that, but I find Faraday gem most useful.
Our application is a API based one wherein the frontend relies on REST API calls to the back end. This sometimes creates a problem wherein the frontend team can't move forward unless the backend API's have been implemented since they invariably progress at different speeds. Is there a way to set up a server so that the front-ent can work independently regardless of the backend status ?
I know this is a bit of an old post but I created a tool just for this purpose and I thought I should share it for anyone who stumbles across it.
It's called Interfake and you can find it at https://github.com/basicallydan/interfake. I frequently use it for prototyping APIs which haven't been built yet, in fact that is my main use of it. I hope that helps.
A common solution that we work with is as follows :
FE and BE contracts/APIs are agreed upon and the back end apis are mocked.
The BE rest APIs use a filter that we configured.
For all the apis that are ready, the filter redirects to the correct api and for all the apis that are mocked the filter redirects to the mock api.
So transparent to the FE team as the BE team is building and completing more apis, they just update the map that the filter looks and and automatically the back end apis get invoked as soon as the BE team is ready to open it up.
So the flow is as follows :
FE ->BE Rest API Server
|API Filter->(for apis updated in the map as complete)-->server/port with actual api
|------------->(for apis that are still being mocked) --> server/port with mock
Hope that helps.