We Keep Coding

Repeated deserializing and serializing when calling API - is there a better way?

I am developing a website along with an API to serve it data and have noticed that my current process involves repeated serialization and deserialization of the same data when an API call is made. I was wondering if there is a better way to go about things. Both the website and API are written in C# using ASP.Net Core 2.0.
My current process is as follows:
1) End user loads website page
2) AJAX call is made from client side JavaScript, calling a C# function in the website.
3) The C# website function calls the API (using a Swagger generated client).
4) The API serializes data and returns it to website as JSON.
5) The Swagger client in the web site deserializes the data back to a POCO class.
6) The Website C# function serializes the data back to JSON to return it to AJAX function.
7) Something is done with the JSON data in the client - inevitably after first parsing the JSON.
Example Code:
AJAX call:
var xhr = new XMLHttpRequest();
xhr.open('get', "/GetData", true);
xhr.onload = function () {
var data = JSON.parse(xhr.responseText);
doSomething(data);
}.bind(this);
xhr.send();
Website method:
[Route("/GetData")]
public async Task<IActionResult> GetData()
{
var data = await ApiClient.ApiDataGetAsync();
return Json(data);
}
API Method:
[HttpGet]
public Dictionary<int, string> GetData()
{
return _logic.GetData();
}
As the above shows the data is serialized to JSON by the API before being deserialized to a POCO by the Swagger client, then serialized back to JSON in the website to be processed client side.
I realize I could simplify this by calling the API directly from the AJAX rather than going through the website but I would rather avoid this for a number of reasons:
1) It would tightly couple the API to the front end of the website, at the moment I have the option of implementing an interface layer in the site to simplify things if the API needs to be replaced in the future.
2) It would reduce my control over who can access the API - at the moment it is locked down by IP address.
Is there a way I can improve this process so the data doesn't have to be serialized twice whilst retaining the Swagger client?

What problem are you actually trying to solve? The time taken to serialize/deserialize the json is tiny compared to the time taken for networked i/o.
At this point I would say you are trying to optimise something without knowing whether it will improve application performance or reduce cost, which is generally considered a waste of time.

Well, you can forgo the client and simply make your action a proxy using HttpClient to fetch from the API.
The client is intended to actually give you C# objects to work with, so it serializes/deserializes the request/response to make it easier for you to work with the API. That's sort of the whole point. What you're saying is that you don't actually want this, so simply drop the client.
Instead, you can make the request directly to your API from the action, using HttpClient, and then simply return the the response from the HttpClient call. Since the API returns JSON and you need JSON, no further processing needs to be done.

Need to create code in asp.net mvc 5 solution to receive and send json strings server to server

I have recently returned to .net programming after a 7 year break.
I need to learn how to write a project within an existing open source asp.net mvc 5 ecommerce solution to receive posted json strings from a remote server running php with cURL, send acknowledgement responses, create my own json strings to post back to the remote server and receive acknowledgement responses. This must all be done with server side code, with no client side component whatsoever.
Serializing and deserializing json is not the issue, its using the correct kind of pages or services to send and receive json on the server without any client component, and using http objects directly. I have no experience or knowledge of creating this kind of project.
This is my question: I have had a look at a couple of tutorials about using .ashx and httpClient and httpContext but found them a little confusing. I would like to find a comprehensive guide about how to use json to communicate server to server with realistic examples. Is there one available?

Sounds like a perfect use case for WebApi. It is made specifically to work with JSON (or XML) requests and should work fine with requests issued by other scripts (not browsers).
There are plenty of tutorials available. Here is the official introduction tutorial.

What I often do to create JSON in C# is make an object/class which I serialize to JSON.
My controller has an function:
public JsonResult FunctionName()
{
var json = new { x1 = 10, y1 = "Hello" };
return Json(json);
}
You can call that function with PHP.

.net Client consuming Axis2 Web Service

I have an .net 2.0 C# client app that has a web service reference to an Axis2 Java Webservice.
The idea is to send some xml data to the webservice, so it can be parsed and inserted into database.
The WS method accepts a single parameter of type 'xsd:anytype'.
Java web service:
public class JWS{
public Response AddData(Object inputXML) {
return Response;
}
}
C# Client:
JWS client = new JWS();
object inputXML = "<xml>some xml data</xml>";
response = client.AddData(inputXML);
There are 2 issues i am seeing when monitored using fiddler.
1) The request has an additional element '<inputXML>' added before the actual xml data.
<inputXML><xml>some xml data</xml></inputXML>
2) The xml is encoded, so '<' is appearing as "<"
I am not sure if this is how SOAP request's are generated but i would like to remove the <inputXML> tag and also, have the xml appear as is without having to replace the special characters.
Is this possible? Is it got something to do with 'Wrapping'/'UnWrapping' Types?
Also, i have used SoapUI to test the java web service and it works well. However, in the request tab, i had to manually remove the <inputXML> tag and submit for it to work correctly. Please help.
TIA

This is expected behaviour under SOAP and the inputXml variable will be decoded back to the original string when passed to your web service method.
However this may indicate a problem with your design, have you considered constructing an object to send to your web service rather than xml data? (As this object will transparently be converted to xml for the web service call anyway).

I found out that the issue is not with encoding but it was interpreted incorrectly on java side when the message was viewed in axis2. So, it is getting decoded properly. Also, the inputxml is now being handled correctly.

SoapHttpClientProtocol: get response as a stream instead of a string?

I'm using a webservice which spits out very large amounts of data in one piece. The response string can be something like 8MB. While not an issue on a desktop PC, an embedded device goes nuts dealing with an 8MB string object.
I wonder if there is a way to get the response as a stream? Currently I'm using the method like below. I tried using a POST request instead, but SOAP is just more convenient (the response is XML and with the POST I have to convert the plain text reply back to valid XML) and I'd like to stick with it. Is it possible to use a different kind of "Invoke" which won't return strings but streams? Any ideas?
[System.Web.Services.Protocols.SoapDocumentMethodAttribute("MyAPI/MyMethod", RequestNamespace="MyAPI", ResponseNamespace="MyAPI", ParameterStyle=System.Web.Services.Protocols.SoapParameterStyle.Wrapped, Use=System.Web.Services.Description.SoapBindingUse.Literal)]
public string MyMethod(string sID)
{
object[] results = this.Invoke("MyMethod", new object[] { sID });
return ((string)(results[0]));
}

If you use the old ASMX web service client infrastructure, then you're stuck with its limitations. One limitation is that there's no simple way to get the response except as deserialized data.
If it were necessary, then you could use a partial class to override the GetWebResponse method to return your own custom WebResponse. This latter would in turn override the GetResponseStream method to call the base version, consume the stream, then to return a stream containing an "empty" web request (otherwise .NET will choke on a stream with no contents).
You might also try something similar by overriding the GetReaderForMessage method. This is passed a SoapClientMessage instance which has a Stream property that you might be able to use. Again, you'll have to set the stream to something that the web service infrastructure can consume.
The better way to do this is with a WCF client. WCF has much more powerful and easy to use extensibility mechanisms.
In fact, you might not even need to extend a WCF client. You might simply be able to configure it to not have this buffering problem at all.

Any web service call is going to return SOAP, isn't it? I don't think a stream could be serialized into a soap packet to be returned from your service. And even if it could, wouldn't the serialized stream be at least as big as the string itself?

I believe the answer is no, there is no concept of a stream for SOAP.
Probably the simplest answer is to have your method:
Parse your response into segments your mobile device can handle
Cache your response in a application variable as a dictionary of these segments
return an arraylist of GUIDs.
You can then have your client request each of these segments separately via their GUIDs, then reassemble the original response when and handle it all the web services return.

ASMX can't do much about this. WCF's BasicHttpBinding can return a Stream to the caller.
http://msdn.microsoft.com/en-us/library/ms733742.aspx

Does WCF automatically URL encode/decode streams?

I'm programming a service for a program that uses HTTP post/get requests, so I handle all incoming requests with a hook method that takes a System.IO.Stream and returns a System.IO.Stream.
When I parse the incoming request (contained in an HTML form) by converting to a string and then using System.Web.HttpUtility.ParseQueryString(string), it seems to automatically URL-decode the data. When I return a file path (a Windows UNC, not going to explain why I do that), I initially URL-encoded the string before converting to a stream and returning it using a return-statement, the client seems to get a doubly-coded string.
So, just to be sure, does WCF automatically URL encode/decode streams for me as part of using System.ServiceModel.WebHttpBinding?

Apparently, it does:
"For RESTful services, WCF provides a binding named System.ServiceModel.WebHttpBinding.
This binding includes pieces that know how to read and write information using the HTTP and HTTPS transports, as well as encode messages suitable for use with HTTP."
from here.