I'm writing a mobile app which at high level does:
Retrieves data from third party vendor in JSON format via HTTP POST request
Filters results based on user preferences and displays results
Periodically refreshes data
My current approach is to create a web service which handles communication with the third party vendor and also takes care of filtering logic, which contains a fair amount of calculation.
The downside of this approach is the extra hop from client's perspective since there will now be two web service calls (client -> custom service, custom service -> 3rd party vendor)
On the plus side, the filtering logic and future enhancements will be completely agnostic of operating system and I don't need to write custom code for Android & iOS.
Is this the right approach?
It is, under the following scenarios:
Third party site requires an API key (or another form of authentication) which needs to be kept secret and can't be distributed to clients,
Third party charges for each API call or throttles the calls, and you want to cache results on your site to limit the number of calls,
Third party API is likely to change, and you don't want to release a new version of client with every change,
There is a likelihood of switching to a different third party vendor,
Your site is more reliable with better uptime than the third party site.
Otherwise, calling directly from the client will be less of a headache, in spite of the extra amount of coding you mentioned.
Related
I want to provide a geolocation API servce so end users can send IP and the API return geo information about the IP.
While the ideal would be to install a database on my server the database providers like Maxmind, ip2location etc suggest to directly query their API service.
This doesn't sound right to me as the end user will have a query to my API + the query from my API to the provider.
Is this doable ? or I should take a different approach ?
Your idea is doable, just that it boils down to whether this is a practical/sound approach based on what you want to achieve. Below are a few drawbacks by doing this based on my opinion.
The overhead cost is too expensive, as it involves the calling to your own API server + the query to an external 3rd party API solution.
The query speed will be slow due to too high the latency.
You solution will be depending on the 3rd party server uptime, which you have no much control of this.
Any point of failure on either your server or 3rd party server will bring down your API.
Unless you have a good reason for this, the best solution would be to host your own geolocation database and build the API service on top. You can either use IP2Location or Maxmind database, whichever you like.
We have web applications that we build internally (server side exposes web-services that are called from client side JS).
We also required to expose our code functionality in REST API.
I wonder - should I also start to use the REST API also for the web application that I build internally?
Originally, the REST architectural style declares that the REST is stateless (http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3). This results in consumers\clients that keeps the state in the client side.
It works well for "rich" clients (mobile applications, etc...) that are built to save the state in their side. But... is it the same for web applications?
Is it good to have server side that expose itself in REST API, and the client side calls those REST API directly?
I see some pros, and some cons.
Pros:
Unified interface - our server side exposes it's API only in one way (REST), for the web application, and for general purposes API
Easy to expose services that we use internally to be used by external users.
Cons:
As said above - browsers are not built to save cache in the client side.
If I have the possibility to use state - why not? It improves performance (less back and forth), and ease on development.
Once we expose the internal API to customers, it restricts us to be very careful with the changes.
Any hints\recommendations?
This is an extremely common and powerful architecture, especially when coupled with heavy front-end clients like AngularJS or EmberJS. The state in that case is held on the client, and passed to the server only what's needed to complete whatever interaction (API call) they're making. It's really clean and scalable, in my experience.
A couple things you need to figure out / handle. Login & "session" info. In general, session stuff doesn't get done on a REST service ,so you have to account for that in various ways. Login is generally done by acquiring a token from the server (e.g. a JavaScript Web Token) and then passing that on further requests. You end up handling expiration on your own.
Using single REST server for all your applications will enable you reuse of the server.
Regarding sessions, in Kaltura we use login to return an encrypted string that holds the user id, his session type (admin/user) and the session expiration, once the client received that session string it will use it for any future API call.
This architecture enable us to save additional information on that session string without keeping a copy of it on the server.
For more API REST server guidelines, see my blog: http://restafar.com/create-new-rest-server/
I am planning to build an application bundle that includes a mobile app, a website and an web service for other developers. Website has the first priority and mobil application has second.
For creating the mobile application ordinarily first i need to create the web service.
What is the way i should follow:
Create web service, than website and mobile application using it.
Create website, than create service and mobile application.
P.S: I will develop the service and website using Scala and Play! Framework
The optimal order will vary depending on priorities and how stable requirements are.
Usually during development, the understanding of the problem improves and the requirements change. This can happen particularly for the user interface. The first usability tests can lead to changes in the application's design and behavior.
A construction order that takes this into account would be:
Create an initial version of the website. Depending on the project this would include a short description of the project, a way to collect emails, and authentication features such as user registration and login.
Create the mobile application, mocking the service layer in the mobile application itself (i.e. using mock service proxy objects). The objective is to discover and stabilize user interface requirements. This process will clarify which services are needed, which operations these services must perform, and exactly which data these operations must receive and provide.
Implement the web service, based on the already stabilized requirements.
Complete the web site, including description of the application's features and benefits, and showing the application's content (e.g. screenshots, videos).
This order assumes the application's features are the main benefit of the project. If, on the other hand, the main value and complexity resides in the web service, and the application is just a thin, optional front-end over it, then it might be more appropriate to develop the web services first and then the application.
With very little experience designing mobile or web based systems, I really have no idea idea what sort of methods are generally used for exchanging information from an application on a phone with a web service on a server. In my scenario, the app is on Blackberry 10, and I think the web service will be run on Heroku.
I want to periodically exchange small amount of information between client apps and the server's web service. I have tried searching for how this might be done, but I have had no success in finding anything helpful. Any sort of information on how I can or should do this would be appreciated.
To clarify a little: I am particularly interested in how small amount of data are typically stored for transfer, and then what mechanisms are generally used for actually sending and receiving the information.
Typically, this is handled via HTTP calls through the mobile device's SDK. I have no idea what the objects are on blackberry, but the typical workflow looks like this:
Write a web service that does something (e.g. calculation, retrieve data, store data).
Publish web service to a web server. This web service has a URL. If you are following RESTful approaches to web services, there would be unique URLs for resources available through the web. Each function that the web service performs uses one of the common HTTP verbs, e.g. GET and POST. You use "GET" to retrieve data from the web via the URL. You use "POST" when you also want to send data to the web.
From the client SDK (e.g. iOS, Android, Windows Mobile, Blackberry), build an HTTP request through the standard objects that are components of the SDK. Sometimes there are open-source libraries that provide wrapper classes that make this process easier. This HTTP request should either just use the URL (in the event you want to make a GET request), or you should build the request via the "body" of the request with the data that you want to send to the server, in the event of a POST request.
Both types of requests typically produce a response from the server, which you then handle and parse using objects and events that are typically components of the SDK.
You then do whatever you want with the parsed response in the context of the client.
Although the specifics of the implementation of this pattern can vary, the pattern is pretty consistent across all the major platforms; it's really the only way to do it.
I am discovering webservices to impliment in my asp.net website. I visited many sites about Why use webservices and read many articles and found out that web services are good when you have something that is used frequently without loading your page.
I want to know some other example scenarios where web services are used.
Whether i can use web services in sending an order form to database or it is just for textbox box auto completion like google and etc.
Note: I know web services can be used from mobile, web or desktop applications.
But My question is When do i use web service in ASP.Net Application?
Some articles read so far
Codeplex
How to create a Web service using Visual Studio.net
w3school
On a Large Scale, Webservices are basically written, when you want to expose your database, your code, to some other user.
By exposing database, means, suppose, you have a large collection of all the pharmaceutical companies in a given region, storing details in db like, medicines they produce, their policies etc etc. And now, you want people to use it(possibly your paid Client, or simply free access to anyone). So what you going to do? Obviously broadcasting working connectionString to your database will be a disastrous move.
So what you do is to make few methods on top of your db i.e. CRUDE operations and expose these methods in your WebService i.e. someone can interact with these methods through a URL and fetch data or send data or both.
Most general use of WebServices is when you want your specific language built( say ASP.NET) logic and data to be accessible to people on different platforms.
Like mobile devices. Their frontEnd is built in fancy framework say like Titanium, but they fetch their data through a Sql Server using WebService built with Microsoft's WCF-Rest approach. They store their data, Synch their data through a WebService.
In a typical example, We had a very large shopping Website, and it was standalone i.e. we were the only users of its database, its data, its users. But then a requirement came, that certain Client wants to model it and make use of its existing data and logic, but they have got JAVA platform. Our entire system was built on ASP.NET 3.5. What to do then. We simply exposed our BAL through a ServiceLayer and gave it a fancy name ServiceBAL and lived (and earned) happily ever after.
These are some business oriented usage of Web Services.
Other simple, mere usage of webService like textBox auto completion, existing user check and so many, am sure, you must have found out during your scout.
Web services are reusable components you can use anywhere. for example suppose you are building order processing system where order can be place by mobile,web etc. So instead of creating a different function for different application or different platform it's better to create a web service of order processing system such as placeOrder or takeOrder web service and consume them on different applications.
Web Services are the means by which devices communicate over the World Wide Web.
Whether you use a mobile application, search engine or an enterprise system, the user piece of the application (the interface) resides on your device.
The data, and potentially the business rules, live on some other server on the network. How your interface communicates with the server piece is the role of Web Services.