consuming web services - how to develop ui pulling results from many sources - c#

I´m looking for books, tutorials or videos displaying best practices for consuming webservices. My main idea is to learn how to manage a user interface were results are pulled from many sources (eg: ebay developer, yahoo shopping xml, etc) and displayed to customers in a list of results. many years ago a website called www.mpire.com used to work in that way, displaying results on demand.
I´m developing with C#, razor, ef 4, sql server.
thanks in advance.

Here is an overview. With this you can start searching more concepts on google.
Learn how to connect to the various API's and retrieve data. You can do this in your controller but it would be considered best practice to create a c# api wrapper for each of the api's you are connecting to. Your application then can use the wrapper to simplify and seperate concerns. For many popular api's .net wrappers are already created and are available on open source sites such as codeplex or github. The documentation for each api is a good place to start. Generally they will reference a wrapper for the language you are working in or may have developed there own you can download.
Once you are retrieving data, then you have to consider if you are going to store the data in your app or if it is always going to call to the api to get the data. Depending on the situation, you can store the data in you database, thus making things faster and reducing calls to the external api. This doesn't work / isn't allowed in all situations but just depends on your use case. If you are going to save the data, you will need to learn about database persistance. Linq2sql is a good place to start because it is so easy. There are good examples on www.asp.net/mvc
Depending on if you are retrieving the data from your database or from the API directly, you will then need to create custom view models for your views. In your controller, you can gather the data from the various sources and combine it into a single object called a view model. From there you pass the view model to your view and then display the data on the page. I would stay away from the asynchronous controllers until you get everything working properly and go into performance tuning. These will add complexity that you don't need as you are learning.

Because invoking remote services is an I/O intensive tasks it would be beneficial to use asynchronous controllers. The documentation contains a couple of examples of howto put them in practice.

Related

Can ASP.Net MVC be used as an API in place of WebAPI?

I'm writing a presentation for my company internally to summarize what I've learned about programming and how it relates to .NET, C#, and all of the key concepts companies look for and I'm a little stuck in how to explain API.
I know how API works, I've written many and I know that it's used to transmit data. The definition I stumbled upon is:
"API is Application Programming Interface, a set of definitions, protocols and tools for building application software... Just as a graphical user interface can be used to transfer data back and forth between person and machine, API is used to transfer data back and forth between machine and machine."
Thinking back to examples of reddit.com and other websites, if you append .json to the end of some websites you're making a get to their website and the information is served up in the form of JSON.
Am I right in saying:
"MVC can be used as API, but WebAPI is a pre-defined framework built to make API a lot more efficient, effective and easy to write"?
Yes.
API is a very broad term, which can be used to refer to any programming interface. You could use any HTTP-based system to build an API, so you could also use the ASP.NET MVC framework for it. It probably would make more sense to use a framework specifically meant for building APIs, but strictly speaking your statement is correct.

Maintain Web APIs consistency in teams

Please feel free for editing the caption of this question.
I was part of a team which develops web applications by using AngularJS and Web APIs. We developed Web APIs for each page and grab data by Angular.
after a while, We realized the most of web APIs are sames, because we could not realized which Web APIs already exists. In some cases, we have same APIs but different routes.
For example, in ShowOrderDetail.html we need to show the user's profile info. A developer implements a Web API to retrieve data from UserProfile ( only 3 fields). However, in other page another developer implements another API to retrieve 5 fields.
I would like to know if you have any other experiences in designing these kind of systems and how handle this issue. Is there other techniques or tools instead of managerial aspects (like setting name convention)?
It doesn't make a lot of sense to create a lot of separate services for the same project, and it's certainly excessive to create a completely separate Web API for every single individual page in the web site. This'll inevitably lead to a lot of redundancy and wasted effort regardless of other means you're using to organize your code (tools, naming conventions, etc.).
I'd suggest reorganizing your services in terms of the operations you're performing regularly, not in terms of one service per page. You can create separate controllers to organize your service into different types of operations (in fact, I'd recommend this - this article has a good description of different ways of organizing code) but again this should be organized in terms of reusable operations, not in terms of individual pages.

Which web application technology should I use for graphs?

I'd like to create a webapplication that allows users to work with graphs. (Retrieve data related to nodes, create new ones, drag them, etc.) I thought it would be a good idea to store the data in a graph database (e.g. neo4j) and display it with some JS-Frameworks (e.g. http://cytoscape.github.io/cytoscape.js/).
Currently I'm not sure which web application technology I should use. Since one requirement is to use microsoft technologies wherever possible I thought it might be a good idea to go with ASP.NET in C#. However, during the first chapter of my ASP.NET book the following is mentioned:
it’s worth noting that ASP.NET is not the best platform for writing
complex, app-like client-side programs
So, which technology should I use to create my web application? Any recommendations?
Well,
from my experience, I think one of the JVM based languages like Java is a save bet, if not the most sexy one. And it works best with Neo4j, and Java 8 is really nice syntax-wise.
For JS-based frameworks, try Node.js and the Neo4j REST API, should work good, too.

Why doesn't PHP need a middle tier, where as other languages do

For web based applications, why doesn't PHP need middleware to run - yet languages like Java, C#, etc do?
UPDATE:
Re-worded: Why doesn't PHP need a middle tier, or business layer separating it from the database, whereas the others do.
Assuming that by the term "middleware" you mean "a middle tier", or "a business layer" the answer is that none of them need it.
For example, there is nothing to stop you in C# (or more correctly, on the .Net Framework "stack") from writing code in web pages that directly accesses the database. Indeed, lots of prototypes start out this way.
The issue here is more around good practice - it is generally considered A Bad Thing(tm) to write web pages (sticking with the same example) that directly access the database and the reasons for this are many. Testability, security, good decoupled code - all these require you to separate your code out, and having several tiers is a natural way to do this.
Why do you not see as much of this with PHP? I think Jeff's latest blog post covers this well :)
I'd go as far as to say that C# (the language), .Net (the Framework), ASP.NET (especially ASP.NET MVC) and much of the documentation and tutorials encourage you to do the right thing and not punch a whole from the web page through to the database.
But there isn't actually anything stopping you from doing it.
The use case that can appear is the following:
You have multiple web apps serving data that is stored in a database. Let's say the web apps are:
Front-end for your desktop web experience
Front-end for your mobile web experience
Front-end for your APIs that you expose to developers
Let's say each front-end accesses the database directly. Then, your eng team decides that the current database should be replaced. Now you have the problem of rewriting code in every front-end.
If you had a middle tier to abstract the actual data store, you'd only re-write one layer of code. Additionally, having unit tests for that middle tier would ensure that the way the middle tier exposes data remains uniform, regardless of the data storage platform.

API that not exposes business Logic

I need to write a WCF services that bring data to reporting tool.
Reporting tool presents data in lazy way, till user not clicked it's not showing the data.
I cannot send everything in once because there can be several megabits of data and because of that I need to send it in portions.
The problem is that I don't want to create a lot of web functions for each report , because this way part of the BL will be in the reporting tool.
Is it possible somehow to make each report run in it's own web session and each time it's asks a next portion of data I will be able to send it back and everything made in the same session?
May be you have better solution to my problem .
There are a number of technologies that could help. I would take a look at WCF Data Services which allow you to do flexible querying (IQuerable) and association traversal which should take care of your lazy loading concerns without having to create a whole load of seperate WCF calls.
Also take a look at SQl Server Reporting Services which is a more general reporting solution that may appeal to you.
Either of these technologies should help you avoid your BL leaking into your reporting tool. There are probably a whole host of similar non-MS solutions that do similar things, but I have listed the two above as your are using WCF, so you are probably more familiar with the MS stack (but maybe that was a silly assumption by me...if thats not the case they will get you started on what to look for!)

Categories