Request/Acknowledge is a service design pattern wherein clients receive an acknowledgement as an immediate response while the original request is processed in the background. The acknowledgement typically contains a token for identifying the background task which can in turn be used to query the processing status of the task. This pattern is employed to reduce temporal coupling which is especially critical for requests requiring a long processing times. Instead of having the client wait for the final response a pull method for querying the status of the task or a push method for notifying the client is implemented. Similarly, the event-based asynchronous pattern in OOP shares the goal of reducing wasted wait time. Request/Acknowledge/Poll is a variation of this pattern wherein a method is provided for the client to query for the status of the task being processed. The other variation is Request/Acknowledge/Callback wherein a client is notified of task status immediately via callback mechanism. The callback variation ensures that the client receives task status information as it is generated but can be a burden to implement because the client must support the callback mechanism. Furthermore, it places the additional burden of tracking and invoking callbacks upon the server. The poll variation is simpler to implement and keeps the client in control of retrieving status information as it is needed.

My Web application is a Single Page Application and its server front-end is a mix of ASP.NET MVC and WebAPI routes. All View routes (actually the only one) allows anonymous access. But all ApiController’s are guarded by AuthorizeAttribute. There’s a special ApiController – SecurtyApiController with the following routes: Login and GetCurrentUser methods (all these routers are mapped onto corresponding methods) allow anonymous access.

I’m currently recording a course for Pluralsight with a working title of “Building Single Page Apps (SPA) with ASP.NET Web API, Knockout and jQuery” targeting to be out by August 31. This is an end to end course that hits hundreds (ok, not quite) of technologies that work together to create a SPA that works across multiple devices and screen sizes. As I’m recording the videos, I thought it might be fun to occasionally blog about the experience as there were many good tips (and trips) I hit along the way. I really wanted to share an end to end demo that doesn’t cover every feature of every technology, but rather how they all work together in symbiosis.

Exposing REST services to the Chrome Postman REST client extension

Here is a nice article that describes how you can use a chrome extension, PostMan, to debug and test an ASP.NET Web API service, which I found on Yao – MSDN’s blog:

I played around with the extension and liked the fact that it allows you to import/export collections of saved requests. I thought I could use that feature to import a list of APIs that are available on an ASP.NET Web API service, and use it much like a test client

It allows you to construct REST requests and receive responses, manage the values and headers that you send. A nice Chrome extension to work alongside your other tools when building REST services.