If I've Single API for Web and Mobile then how can accomplish following things.
1.In web I need to display 10 fields but in mobile may be 3 fields only ?
2.Basically we will have tight coupling on DB proc side as well if there is a change(Requirement) for WEB, then it could be hit Mobile as well ?
3.Testing -> May be lot of testing for all platforms ?
Simple solution is that you add a extra field into your API maybe call it channel, then use that channel field to indicate web or mobile channel.
Related
When reverse engineering an API, is there an advantage to looking at the mobile app rather than the web client? Looking at tutorials online, it seems much more common to focus on the mobile app, and I'm curious why this is. One guess: APIs used by mobile apps can only be deprecated slowly, since people can have stale versions of the app on their phone for months. Are there other reasons to prefer reverse engineering the mobile API?
Your guess about mobile APIs being deprecated slowly is a valid one and most significant argument in favour of choosing mobile API over web API.
Basically developers make new versions of mobile API either with new endpoints or keep old endpoints which have slightly different behavior depending on request parameters.
Regardless of the way they pick you are basicaly safe to keep your code as long as resource is alive - possibility of API change is very small.
Web APIs can change dramatically overnight because clients get new front-end code simultaneously along with API changes, i.e. API got changed along with clients.
Also quite often Web APIs provide responses which contain ready to display HTML data which is hard to digest(parse properly) sometimes.
Also it is sometime easier to reverse engineer parts of java byte code (to see the logic behind token/clientID generation) albeit it being obfuscated than trying to get understanding of obfuscated and minified javascript code.
I am looking to develop a cross platform mobile app involving real-estate. I have looked at Zillow's API and I think that will be one of the API's I utilize.
https://www.zillow.com/howto/api/APIOverview.htm
My question is if I were to utilize their API as well as those of some other real estate sites, would it make more sense for me to call those APIs directly from the mobile applications, or would it make more sense to have a proxy server, possibly with my own databases compiled from these sites, that the mobile application would call? I have only read the basic overview of the Zillow API, but it looks like it is limited to 1000 calls per day. I understand it is a fairly general questions. If there are any more details that would help to make a better answer, please let me know.
Also, if you know of any other free/cheap real-estate APIs, can you please provide them?
Thanks
Not exactly sure what your metrics are.
But generally speaking, it is a bad idea to hook your mobile app directly to third party API for the following reasons:
You do not control the API, if the third party changed their API your app won't work, the user would have to upgrade. But if you isolate the mobile app by connecting to your server you have more control and can have much longer life.
Caching/rate limits. You can get the data from the third party and store it (if you are allowed) then share the data with all your users
Multiple datasources: Usually you get the data from multiple datasources, so aggregating the data on your server then send the enhanced data model to the app is a lot easier than pulling data from different sources and compiling them on the app itself.
The question is more targeted at server side development.
When writing a REST API, I want to write it in such a way that it can be consumed by both desktop and mobile applications.
Could see two possible approaches:
Each API should support pagination and the responsibility should be delegated to the client of how much data should be fetched in one go. So , mobile apps will ask for fewer pages in one go and desktop applications will ask for more.
Separate APIs for mobile devices hosted separately. The front-end web server can check the user agent (i.e. source from where is request is coming) and if it's a mobile device, then re-route the request to the server hosting the APIs for mobile devices.
Interested to know more strategies around this.
Appreciate your inputs.
I would suggest a bit of both (1) and (2), here's how.
Instead of re-building whole new api for mobile itself, Have adapters for all the supported devices. i.e have a layer on top of you REST API implementation which renders/instructs the underlying service to return the content suitable for selected mobile device.
coming to pagination, you can parameterize the pagination as an input from the Abstraction mentioned above.
I would recommend something closer to option (1). If the main difference between the clients will be the amount of data they request at a time, it seems trivial to add some kind of query parameter or HTTP header to the REST API indicating how many records to return, for instance.
Relying on checking the User-Agent header may require you to maintain a list of known client user agents and match against them, which would be an additional maintenance cost of a separate API.
We have developed a SOA product which uses WCF and WIF with a custom Security Token Service servicing clients written using MVVM and WPF and even a Sharepoint integrated Silverlight solution.
A requirement has now been raised by one of our customers to produce a HTML5 web front end so they can access these resources via an iPad hosted web application.
This is obviously new territory for us and raises several questions we are struggling to answer via the web.
How much of WCF/WIF is supported by HTML5's Websockets? e.g. IssuedTokenWSTrustBinding & WS2007FederationHttpBinding.
Do we need to rewrite huge swathes of our MVVM code, or it is possible to bind HTML5 to a C# ViewModel?
Any insight into any of these questions would be greatly appreciated!
Websockets are just... Websockets they don't do anything fancy beside data transport. So it will not handle anything as IssuedTokenWSTrustBinding or WS2007FederationHttpBinding.
Normally a mobile application should differ from a full desktop browser application, there are things which must be taken into consideration such as: navigation, image sizes, amount of data used in the traffic. Every thing has to be kept at lowest rate as possible. If you don't mind ignoring all the above, then the answer is yes, you can add the required HTML5 functionality into your Views/ViewMOdels.
I was wondering where I can start looking for some introduction/help/tutorials to WCF?
My application scenario is that I want to write Windows Phone 7 app which can save/get data into SQL Server. I assume that WCF is the right choice. At first screen I would like to make some simple login page based also on sql table
I strongly suggest you to look at ASP.Net Web API. It embraces HTTP and can be consumed easily across devices and platforms.