Http Headers and RestException StatusCode

Nov 16, 2010 at 1:40 PM

It would be cool if you add a support for Parameters send as Http Headers.

I tried it with the source code and it worked well. I added these lines:

 

// See if the method param is part of the headers
if (context.Request.Headers.AllKeys.Contains(param.Name, StringComparer.CurrentCultureIgnoreCase))
{
    // Param found in Headers, so ASP.NET will have already put the name/value pairs in the Request.Headers bag for us.
    string sVal = context.Request.Headers[param.Name];

    // The values are passed as strings, and have to be built in .NET types
    addSystemType(param.Name, sVal, param.ParameterType);
}

 

at the beginning of the ParameterInfo loop in getMethodArgs and changed the UriTemplate and QueryString check to else if, so that the headers have the highest priority.

 

Althoug it would be cool if you extend the RestException Class with a HttpStatusCode Property.

Here are my changes:

[JsonIgnore]
public HttpStatusCode ResponseStatusCode
{
    get;
    set;
}

// ********************************************************************************
// ** Constructors ****************************************************************
// ********************************************************************************

public RestException()
	: this(HttpStatusCode.InternalServerError, "Unknown RestException error")
{ }

public RestException(string message)
    : this(HttpStatusCode.InternalServerError, message)
{ }

public RestException(HttpStatusCode statusCode, string message)
	: this(statusCode, message, null)
{ }

public RestException(string message, Exception innerException)
    : this(HttpStatusCode.InternalServerError,
        message,
        innerException == null ? null : innerException.GetType().Name,
        GetErrorDetailsFromException(innerException),
        null)
{ }

public RestException(HttpStatusCode statusCode, string message, Exception innerException)
	: this(statusCode,
		message,
		innerException == null ? null : innerException.GetType().Name,
		GetErrorDetailsFromException(innerException),
		null)
{ }

//
// Now the 2 main constructors, that all of the above constructors call.  One takes an exception, the other just a string message.
// Both call the base Exception constructor.
//
public RestException(HttpStatusCode statusCode, string message, Exception innerException, string errorType, string extraInfo)
	: base(message, innerException)
{
    ResponseStatusCode = statusCode;
	IsRestException = true;
	ErrorType = errorType;
	ExceptionDetails = GetErrorDetailsFromException(innerException);
	ExtraInfo = extraInfo;
}

public RestException(HttpStatusCode statusCode, string message, string errorType, string exceptionDetails, string extraInfo)
	: base(message)
{
    ResponseStatusCode = statusCode;
	IsRestException = true;
	ErrorType = errorType;
	ExceptionDetails = exceptionDetails;
	ExtraInfo = extraInfo;
}

And the WriteRestException Method in RestResponseHelper was changed to:

public static void WriteRestException(RestException ex)
{
    HttpContext.Current.Response.StatusCode = (int) ex.ResponseStatusCode;
    WriteJsonResponse(ex);
}
So if the user throws a RestException in code he could set a HttpStatusCode directly.

 

Thx for the great Work!

Gerrit

        [JsonIgnore]
        public HttpStatusCode ResponseStatusCode
        {
            get;
            set;
        }
Coordinator
Jan 25, 2011 at 4:34 PM

Sorry for the late reply on this.  These changes have been implemented, and I should be committing them later today.  Thanks for your contribution!  I especially like being able to use http headers.  Well done!

 

Also, while I did include the changes to the http status code in RestException, if you're using RestCake, take a look at Examples/AddressBook.Web/Examples/ErrorHandling-New.aspx.  Error handling has been worked over quite a bit in RestCake.  The short version is that a yellow screen of death will never be sent to the client; they'll always get a json-serialized RestException object.  But, the exception remains unhandled in the application so that if there's an Application_Error handler, it will still fire (for logging, etc).  The new example page should clear it up.

 

Thanks again!

 


Sam