I build my ExtJs app using ExtDirect call (stores, forms or any action). The problem is that in order to code well you need your direct calls functional, which is hard to do it fast.
Is there any way in having "direct calls" mocked up?
In this way the front end developer will write from the beginning in JavaScript the specs for backend responses. WIth only one flag in the app, the code wi ll know to make he righ calls to the server so the backend developer would be able to focus in writing backend responses having some functional JavaScript code.
Related
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!
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 have a desktop application [Data Analysis and Report Generation] built in VB. I would like to make this application accessible to all the users in our corporation, from their web browsers. What is the best possible way to achieve this?
One way which I have thought is to write a simple web form that would take the input from the user and apply logic on the server and generate results. Again, the limitation would be at the output screen as it is the real time output being generated.
Any leads would be highly appreciated.
Desktop App is way different from web app. To allow multiple users, a web app is suitable. For this you will have to use several technologies.
The UI has to be build using html, css and javascript (like jQuery).
The back end, can be VB if you are doing working with asp.net or php etc.
For real time output, you'll have to use ajax to allow communication between a browser and sever without page refreshes
An ideal choice for the front end logic, would be to use a frontend framework such as AngularJs by google.
However, all this does have a high learning curve and is difficult to build something using all this on the first day or even week unless you already know most of this.
So. I have embarked on the journey of learning Laravel in the last couple of weeks, and am thoroughly enjoying it.
It has come time for a site redesign and I thought it was about time to tighten up some of our functionality, so I am making the switch from CodeIgniter to Laravel.
I was wondering whether it is worth starting off with a RESTful API layer in Laravel (easy enough to create) and use it as a base even for the web application. In the future we are likely to build a mobile app that will need to use the API. So:
Is it worth having the web application connect to the API
and what is the easiest way/s to make calls to the API without having to write a bazillion
lines for cURL everytime I want to make a request?
It is definitely worth it.
I am currently redesigning a messy PHP code for an established hosting company turning it into beautiful Laravel code. I already have a mobile app working with it - Laravel makes it easy to return JSON data with one line -
Response::json('OK', 200);
or
Response::eloquent(Auth::user());
or
$tasks = Task::all();
Response::eloquent($tasks);
You don't need to use CURL as far as I know.
You can make all requests with simple AJAX, jQuery would simplify that.
Also using some MVC JS framework would help you make the application code structure more elegant for the client side, and the advantage is that you can easily package that into PhoneGap when you are ready to have your API take some real testing.
Today I posted on my blog about a simple example that you can try to see if this approach is worth your time : http://maxoffsky.com/code-blog/login-to-laravel-web-application-from-phonegap-or-backbone/
Check it out and accept the answer if you think it's on the right track.
As always, your results may vary, but this is exactly what I'm going through at the moment. I'm migrating a large .Net site with this API architecture and I've decided to keep it for Laravel.
I personally decided for this because:
More scalable. I can setup api.domain.com and then add additional
boxes/vm/whatever as our traffic grows. In fact, you could load
balance just the api by "round robin" or multiple dns entries for
that domain.
Future proofing for new sites and apps. Sounds like you're in the
same situation. I can see an app or two being added in the next year
or so.
Lost cost. You'll already be laying out your controllers, so really
it can be just a matter of setting them to RESTful and making small
tweaks to accommodate.
To be fair, some counter points:
Possibly additional load time, from processing through the API, though this should be minimal.
Additional security items to consider if you'd like to lock things down to just your app.
Either way, welcome to Laravel!
and what is the easiest way/s to make calls to the API without having to write a bazillion lines for cURL everytime I want to make a request?
#Sneaksta try postman chrome extension for calling rest services. you can create forms in this extension and pass data from these forms to you Rest services
https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm?utm_source=chrome-ntp-icon
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.