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.
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