Last pieces of the mobile app in the Web API puzzle

In the ASP.NET Web API services I’ve been developing, I ran into an issue whereby the POST data I was sending wasn’t being received by the Controller. The parameter of the Controller was a string as I was sending JSON data, but this wasn’t working. I kept getting the error that the POST data was null when I was expecting it to contain my JSON data.

After much head scratching and Googling I eventually found this very useful article[^] that explained my problem and the various solutions. I opted to change my Web API parameter to JToken as this was a simple fix and got me working again quickly. I need to post different shaped JSON documents to the Web API hence why I ran into the problem. The endpoint is also invoked from our mobile apps with Javascript, thus necessating the need to send data as a JSON document. So changing the parameter from string to JToken fixed the issue.

Next problem I encountered was when invoking the Web API endpoint from our mobile app. I was using an AJAX call to POST data but getting an error. It turns out the problem was because I was breaking standard browser security. Browser security prevents a web page from making AJAX requests to another domain. This restriction is called the same-origin policy, and prevents a malicious site from reading sensitive data from another site. However, sometimes you might want to let other sites call your Web API. In our case, we wanted our Web API to be invoked from mobile app clients.

In order to allow this, I needed to enable CORS on the Web API that was being invoked by the mobile apps (there was only one). Cross-Origin Resource Sharing[^] (CORS) is a W3C standard that allows a server to relax the same-origin policy. Using CORS, a server can explicitly allow some cross-origin requests while rejecting others. CORS is a safe and reliable technique for allowing cross-origin requests.

I installed the CORS Nuget package and enabled CORS on the Controller, and everything now works. We can post data from the mobile app to our legacy back-end system via Web API endpoints (which in turn use an Azure Service Bus).

Now that the last pieces of the puzzle have been solved it’s good to see all the moving parts in the architecture working together.

Our mobile app user fills out a form and submits the data. The data is packaged into a JSON document and posted to our Web API which adds a message to an Azure Service Bus. An Azure Function that is bound to the Azure Service Bus listening for incoming messages, picks up the message and routes the request onto a routing engine where it is determined where the request needs to be routed to. Requests from our mobile app are routed to our back-end legacy system, where a task is created from the request so that a member of staff can process the request data from the mobile app user.

This all happens seamlessly and is incredibly responsive thanks to a carefully thought out and designed architecture by yours truly

Image for post
Image for post

A father, cyclist, vegetarian, atheist, geek and multiple award winning technical author. Loves real ale, fine wine and good music. All round decent chap.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store