We are developing a dashboard application. In the home screen it has four charts and list view. The data for these charts and list view are stored in different tables in the backend database. We are planning to create web services for fetching the data from server.
My question is, do we need to write separate web services (in this case 5 web services) for fetching the data or can we create a single web services that returns all the data in a single call?
If we write different services, then we need to invoke five services from the mobile device (iPad/Android Tablet). If we write single service, the response time will be delayed due to the joining table in the server side.
We are creating our application using Sencha touch framework. Our app is a cross platform mobile application. The web services are writing using restful wcf services and it returns JSON.
Please give ur your suggestions
Related
We are creating an integration application which will sync data between Dynamics CRM and Xero. We are now at the stage where we need to decide which type of application we should use to connect to Xero and perform operations.
The application will be used by multiple Xero Customers. So our application should serve multiple Xero users.
We will have web api which will call on Dynamics CRM events(Create, Update Contact etc.) and will update the data in Xero.
So our web api should connect to Xero and perform operations in Xero. We tried using Public application but it generates the token that is valid for 30 minutes. The web api should communicate to Xero without any time limitation.
Please suggest how we can achieve this.
You should begin developing your integration using a public application, and get in touch with Xero to register for becoming a partner application (which will give you the ability to request long-term tokens). The process is documented here: https://developer.xero.com/documentation/auth-and-limits/partner-applications
I'm building a Web application as an interface for a Business Network. I would like to reuse some of the REST Server functionality (e.g. GitHub login and storing cards in a MongoDB database) but do a few things differently. For example, I want to generate all cards on the server, so that the users won't have to upload them. Plus, I need to serve the static files from somewhere. I'm trying to figure which architecture I should use.
The app would serve 10's - 100's of users, potentially scaling to 100's of 1000's.
So far, I thought about these options:
1. Have a different app on a different port; REST endpoints called from the client.
2. Same, but REST endpoints called from the server (also means that I'll have to forward the login process somehow).
3. Extend the REST server with custom functionality (is it possible?).
4. Don't use the REST server but steal some of its code to use it in my app.
Questions:
Is it possible to extend the REST server with custom routes?
What is the recommended architecture for a Web interface for a Business Network in production?
Yes you can take the REST server and customise, its open source
See https://github.com/hyperledger/composer-knowledge-wiki/blob/latest/knowledge.md#information_source--node-js-application-development-questions-eg-build-real-time-apps-login-etc for some insights, resources and guidance. The business network is essentially a smart contract (including transaction logic, code, queries, access control lists etc etc) deployed to a blockchain runtime (running as native chaincode in Fabric). Your web interface to interact with the ledger (ie through business network cards stored in wallets (whether server based or cloud based ) could be using Angular (app) / Typescript / React JS (for UI elements) but the salient point is that you can interact with the deployed business network card using the Composer APIs, JS and REST. The application users would interact from the app, using their business network cards, which connection info, the user's blockchain identity and some other metadata. See more info here on Composer's architecture.
I am trying to build a mobile application that needs data from an Azure SQL DB. Best practice looks like building a web service in between.
However I am getting lost in the number of solutions.
Which specific Azure component do I need to use to have a future-proof solid solution?
How to handle security between this component and the Azure SQL DB?
How to handle security between the mobile application and the Azure Component?
The best way forward is to use an ASP.NET Web API with ADO Entity Frameworks and publish the API to an Azure website. Use REST services to call the Web Api from your mobile app.
So basically:
1) Fire up VS and build a Web Api that will handle your database using ADO Entity Framework and the controller for your API. Check this: http://www.tutorialsteacher.com/webapi/web-api-tutorials
2) Publish the Web Api to an Azure website/app through VS. Make sure you have Azure services installed on your VS.
3) Call the Web Api from your mobile app using REST services to work with the SQL database. You will need an HttpClient class to do this, you can get it from NuGet.
For security of your Web API, check this: https://www.asp.net/web-api/overview/security
I have an Azure Mobile Service running connected to a database with 3 tables, on the management portal of the database I can create Views based on them...the question is...how can I access the view through the Mobile Service? is this possible with Azure Mobile Services? or should I be using a regular web Service?
What I'm looking for is a way to access it like I would do with a table...for the table I just go to the URL and I get a JSON, that's what I would like to achieve.
you should use regular web services. Windows Azure Mobile services is meant to be very simple in simple cases rather than an all purpose tool.
Still, you could override the read operation on a table to return other results. You may want to use http://msdn.microsoft.com/en-us/library/jj631631.aspx and http://msdn.microsoft.com/en-us/library/jj613353.aspx as starting points.
If you go to the portal and just add the name of the view that you have created it seems to work.
eg.
My Mobile Web Services service is called 'PTView'
create view PTView.vwMcPeople as
select * from Person where surname like 'Mc%'
on the Data tab of your web service create a table with the same name as the view.
Use/ Download the SDK for Azure mobile service and then you can access your data using API provided.
Azure mobile service is not accessible directly from URL.
Lets have an example scenario:
Client opens a web site and finds the sum of two numbers which he enters from the textboxes.Then clicks on the ADD button.Two parameters are HTTP GET'ed to server where PHP code is written to add the numbers and result is echo'ed.
Based on this scenario could anybody explain the difference between Web services and application?
In your case if you have User Interface for providing two numbers and then getting the result, it should be called a web application. But if you have an API exposed to receive two numbers and return result over http , then it should be called a web service.
At low level, both Web application and web service are kind of same thing. But the main point is that web services are for machine/program to machine/program communication whereas Web application is for Users.
I'd say that web applications are intended for users and web services are intended for other applications. That's the most important difference. Web applications usually present data in HTML which looks nice to the user and web services usually present data in XML which easy to parse by other applications.
A person drives a car. That car could be powered by an internal combustion engine, electric motor, or nuclear reactor. The power source doesn't matter to the driver though, as all they need to see are the controls and the road ahead.
The application is the car. Web services are the nuclear reactor.
To add 2 no.s we write a web service, to subtract we write a diffrent web service, however calculator is an web application that uses add,subtract and many other webservices in combine.
Lets take an example of Google search.
We can use Google search in two ways. First, we can visit http://www.google.com and put out query for search. Google the returns the result. Second, we can integrate Google Search in our websites with custom search API.
In first case Google Search is acting as web application while in second example it is acting as web service.
Here we can point out few differences,
User interacts with web application while machine interacts with web service.
To access web application, one must visit application. While web service can be access from anywhere (from any application which integrated it). We don't need to visit the service explicitly.
A webservice is equivalent to a method in java that has a web wrapper around it. It lives on the server and it can be sent data / queried etc. and may or may not return a result. It does not have any front end it can only be accessed via http get, put, delete etc.
A web Application is a fully functional piece of software that lives on a sever that is designed to help people achieve a task. This would have a front end that would allow users to interact with it / enter data etc.
A web application could use multiple webservices to achieve its goal / end result
There is little difference between web application and web services.
Web Application: In web application when user request any data then the server embeds the response into some HTML and forward it to the user and on browser the HTML is rendered.
While in web services it's done differently that when some user requests for some data then the server returns it a json or XML array of objects and the data can be displayed by anyway the web designers wants.
Thanks Hope it resolves the matter.
Web service is for application consumption , invoked through web application
To communicate with webservice data should be sent as SOAP message or as REST i.e XML over HTTP
Most of the times web service is not part of application because to facilitate the use by other web applications and it is not for direct consumption to end users
Web application is for human consumption invoked directly by GUI which may or may not use web service for giving response