Developer Experiences & Lessons Learned
Documenting solutions for common and unusual problems.

---

When a new ASP.NET Web API project is created, the WebApiConfig.cs class contains a single route:

config.Routes.MapHttpRoute(
 name: "DefaultApi",
 routeTemplate: "{controller}/{id}",
 defaults: new { id = RouteParameter.Optional }
);

In order to enable RPC style routes (like those used with non-Web API projects), add another route before the default:

config.Routes.MapHttpRoute(
 name: "RestPCApi",
 routeTemplate: "{controller}/{action}",
 defaults: new { action = RouteParameter.Optional }
);

All done, now the Web API project will route URLs just like the MVC 3/4 project. Here is what the finished file looks like:

using System.Web.Http;

namespace hansen.blog.api
{
 public static class WebApiConfig
 {
  public static void Register(HttpConfiguration config)
  {
   config.Routes.MapHttpRoute(
    name: "RestPCApi",
    routeTemplate: "{controller}/{action}",
    defaults: new { action = RouteParameter.Optional }
   );

   config.Routes.MapHttpRoute(
    name: "DefaultApi",
    routeTemplate: "{controller}/{id}",
    defaults: new { id = RouteParameter.Optional }
   );
  }
 }
}

---

The official documentation for creating database objects can be vague and hard to understand for anyone just starting out. So let's talk about how to create views and procedures....


Schema-dir/
     Schema.xml
     Stored-procedures.db-oracle/
     Views.db-oracle/

---

I am writing an application for work, and recently made some improvements that are ostensibly "good". See, I improved the speed at which some of the operations occur. It is now so fast that my users wonder if anything even happened at all. So how did I solve this "problem"?

I solved it by introducing a 1 second delay in to the processing (after everything has completed). So now the user feels like the system was "thinking" or "doing something" when in fact...the system actually finished its work and is doing nothing!

I leave you with a Star Trek quote:
Data: She brought me closer to humanity than I ever thought possible, and for a time...I was tempted by her offer.
Jean-Luc Picard: How long a time?
Data: Zero point six eight seconds, sir. For an android, that is nearly an eternity.

---

Here is the envelope structure I use for my JSON messages.

{
    "message_id":"message_id_000001",
    "status":"[SUCCESS|ERROR|WARNING]",
    "status_code":"[200|404|500|etc]",
    "messages":[
        {
            "message_order":"1",
            "message_type":"[ERROR|WARNING|INFO|DEBUG|TRACE]",
            "message_format":"[HTML|TEXT]",
            "message":"message text here"
        },
        {
            "message_order":"2",
            "message_type":"[ERROR|WARNING|INFO|DEBUG|TRACE]",
            "message_format":"[HTML|TEXT]",
            "message":"message text here"
        }
    ],
    "data":[
        {
            "data_1":"data 1"
        },
        {
            "data_2":"data 2"
        }
    ]
}

The structure is pretty verbose, it's almost like using SOAP XML calls...almost. The important point for me, is that I can easily debug the JS code my application is processing. I still have not figured out the security part though. Most of the time I actually forget (I'm getting old!) what the actual structure of my response is, so I just create a handy class based on a HashMap. Why a HashMap? Because I do not know what other data may be required for transmission to other clients. This way I can add them without having to upgrade everything else.

Here's the class I use:

package info.markhansen.json;

import java.rmi.server.UID;

import java.util.Collection;
import java.util.HashMap;
import java.util.TreeMap;

public class JsonEnvelope extends HashMap {
 public static final String STATUS = "status";
 public static final String STATUS_CODE = "status_code";
 public static final String DATA = "data";
 public static final String MESSAGES = "messages";
 public static final String MESSAGE_ID = "message_id";
 
 public JsonEnvelope() {
  // Create a unique ID for this message
  this.put(MESSAGE_ID, new UID());
  // Make sure the messages array is not null
  this.put(MESSAGES, new TreeMap());
  // Set the default status to success
  this.setStatusOther("SUCCESS");
  // set the default status code to success
  this.setStatusCode(200);
 }
 
 public String getMessageId() {
  return (String)this.get(MESSAGE_ID);
 }
    
 public void setStatusSuccess() {
  this.setStatusOther("SUCCESS");
 }
 
 public void setStatusError() {
  this.setStatusOther("ERROR");
 }
 
 public void setStatusOther(String status) {
  this.put(STATUS, status);
 }
 
 public void setStatusCode(int statusCode) {
  this.put(STATUS_CODE, new Integer(statusCode));
 }
 
 public void setData(Collection data) {
  this.put(DATA, data);
 }
 
 public void setMessages(TreeMap messages) {
  if (null != messages) {
      this.put(MESSAGES, messages);
  }
 }
 
 public void addMessage(String message) {
  final TreeMap messages = (TreeMap)this.get(MESSAGES);
  messages.put(new Integer(messages.size() + 1), message);
 }
}

---

Usually when working on the interface for an application, there are multiple items which require an $.ajax call of some sort. Auto Complete fields, tables, drop downs, combo boxes, you get the idea. Now, before I learned about JQuery deferred objects, I would have an $.ajax call inside of my event handler methods. I know it's not the best way, but it's the most straightforward way I could implement it when I first began to use JQuery. The code ended up looking like the following:
With the $.ajax call isolated, I can now use this call in multiple places through out the site without having to repeat the code. It's nice and DRY (Don't Repeat Yourself...Dum Dum) now.