I'm a PHP developer, learning Umbraco and ASP.NET. I consumed an external API before using Guzzle in Laravel, however everything I found so far on Umbraco is very different to what I'm used to.
Now I'd like to consume external API in Umbraco, and return JSON objects into views. For example, one JSON object is an event (a concert or a sport event) which contains values like image, date, description. These will be passed into a view. I should be able to do this once I wrap my head around how to consume the API.
How would I consume external API on Umbraco? I'm unsure where to start. Are there any good tutorials available out there?
On server side you can look at this library Restsharp that helps you to consume external http or rest api. You can easily install it via nuget.
For client side you can use JQuery to do Ajax call but need to take into considering CORS.
Related
I am trying to build a single-page application with an ASP.Core + Angular 4 stack. The server is supposed to provide view components, which will be rendered client-side and populated with additional data.
The best way to create components would be utilising ViewComponent mechanic on the server, which allows me to effectively create HTML layouts and populate my HTML components with data from DB. Alas, I have not yet found a way to transfer the data to my Angular 4 client app. The ViewComponents are not static resources, meaning I (most likely) can't transfer it as JSON-data, and even if I could, I'd have to teach my client how to unwrap it back into html, which would increase the load on the client.
I have confirmed that JQuery calls can be made to receive IViewComponentResult responses, but I am yet to find a way on how to achieve same results in an Angular component. Any help would be appreciated.
Usually with this stack you use .NET Core as the backend meaning you use it to write the Web API code which interacts with the database. The Angular side of things would have services which call the Web API via http methods and present/manipulate the data in component.html/.css/.ts files.
You can read through a guide such as this to get an idea of the structure and flow of the stack. Everything you mentioned in your 2nd paragraph can be achieved through this architecture without the worry of transferring ViewComponents.
I'm building a site in Symfony 2.0 that has a fair amount of AJAX, which builds page content with data it gets from an API, like: http://mysite.com/api/pictures/list
Data is handled using Repositories, which are sometimes used in page code so that string of images you see might come from the controller using the PictureRepository, or via Ajax using the API which accesses the PictureRepository.
I'd like to use Memcached to ease the database load, but am not sure where to put the caching code. Is it best to cache the database result, or the API result? Or is the difference negligible? Having the memcached logic inside the Repository would mean writing the code once (regardless of whether it's accessed via the API or directly), but it seems like it would also make sense to avoid accessing the Repository whenever possible.
Thoughts?
My opinion is that memcached should be used for session storage.
For your purposes you should better think about using of Varnish as http cache.
After that, you can configure your application use ESI.
At least, that is how we do it in our applications ;)
I want to make an ajax call from jQuery to my server. Basically, I want the request to be sent as a POST with a content-type of x-www-form-urlencoded and the corresponding parameters (parameter1=X¶mter2=Y¶meter3=Z). I want the response to be JSON.
The server environment is .NET. I have been experimenting with the three methods below, but have not been able to get one to work quite right.
ASPX - Using an aspx to process and return JSON, I can get it to work, but I need to serialize the JSON myself. This is possible, but I was hoping for something more convenient. Also, correct me if I'm wrong, but I would imagine that aspx pages have a lot of extra overhead involved since they are expected to do more than just execute a method and return simple JSON.
ASMX and WCF - With asmx and WCF, I can get it to return JSON, but only if I send JSON in the request.
What is the best server side "framework" to use for this request / response type? .aspx, .asmx, or WCF? Since I have been able to at least get aspx to work for this, is that even an appropriate approach?
I've seen other products out there that expose an API via a web service and use a name / value querystring request format with a JSON response type, but this seems to be a difficult feat to accomplish in .NET.
You're right that ASPX pages bring extra overhead. Even if you're not using the WebForms framework at all, requests to ASPX pages still must filter through the entire page lifecycle.
If you prefer that sort of low-level approach, reading QueryString parameters and responding with manually serialized JSON, an ASHX HttpHandler would probably be the best solution.
Personally, I prefer ASMX services. Sending JSON parameters in isn't very difficult (and you'll probably end up doing that anyway once you begin sending nested objects or collections, which is a mess via simple key/value pairs), and it's nice to avoid the needless ceremony of deserializing and serializing during every request.
People will tell you WCF is the correct solution since it's newer, but .NET 4's WCF isn't currently a great fit when you're using jQuery. It's not as flexible when dealing with DateTime and Enum types, and it has unwieldy Dictionary serialization. WCF's new WCF Web Api solves those problems though if you want to try something a bit ahead of the curve.
I've used.
.aspx -> just exactly the way you are doing it
.ashx -> similar to the .aspx except less overhead in the page lifecycle.
.asmx & wcf -> what's wrong with passing JSON in the request?
MVC -> return JsonResult. This one is my favorite when I'm not making an entire
API (for that I use WCF), but instead I just need one or two requests
to return JSON. This, of course, assumes that the entire site is
written using MVC, otherwise it would be overkill to install the
framework for just a few calls.
If you are okay going down the WCF route, may I suggest you look at the WCF WebAPI project from Microsoft. This project sits on top of WCF and provides some niceties and simplifications when it comes to client access (.NET code or jQuery Ajax). Here is a walkthrough using jQuery to POST form-urlencoded data. There are other walkthroughs demonstrating other related tasks there as well.
These services can be hosted like any other WCF service, and even hosted right within the same ASP.NET project as the rest of your site.
At this time, the project is in early development and has some "Go-Live" restrictions, but depending on your project needs, this may work out great, it has for us.
I use the ASP.Net ScriptManager to load the scripts needed for calling WCF services via HTTP/JSON. I am optimizing the total size of my pages (including scripts) and I see that Microsoft's AJAX library is the biggest file that I have at 96KB. Is there anyway that I can get a version of this file with just the features I need loaded?
Or since I already have jquery, should I use that to call my WCF JSON service instead?
Cheers,
Jon
WCF JSON services degrade gracefully down to working as a standard webservice, so you should have no problems using jQuery to post and retrieve data from them. You may lose some of the integration bells and whistles, but as someone who has taken the path you're suggesting, I can say that I don't miss it at all.
The only problem might be if you're using advanced WCF feature like 2 way connections, or guaranteed connections.
Does anyone know of a good article or tutorial on the Internet demonstrating the use of GWT leveraging a (ASP.NET) web service cross domain?
To my knowledge, interacting with either XML or JSON should be possible from GWT, but becomes a lot more difficult when the web service is on a different domain. I've tried finding an article that demonstrates this setup, but without any luck.
There are a few options available:
use the Cross Site linker - it should make cross domain request easier, simply add <set-linker name="xs"/> in your module file (*.gwt.xml)
window.name hack :) Be sure to read the post with the original dojo proposal
JSONP
many others ;)
But first I recommend reading http://code.google.com/webtoolkit/tutorials/1.6/Xsite.html - it should get you going :)
I was initially going for a JSONP approach (as suggested by Google), in order to do cross site AJAX calls in JavaScript, but ended up with too many hacks that I had to incorporate into the ASP.NET web service in order for it to work.
The solution, in my case, was instead to use GWT RPC to a JAVA servlet, acting as a proxy, which then would call the ASP.NET Web Service using SOAP. The SOAP Java classes was generated using the wslist tool that is part of JAX-WS project (as demonstrated here).
Using the GWT RPC, I was still able to call the JAVA servlet asynchronously, giving the user a seamless experience.