ServiceStack Routing with ravendb ids

Question

I've an entity with an ID of

public string ID {get;set;}    
activities/1

(which comes from RavenDB).

I'm registering the following routes in my ServiceStack AppHost

Routes
    .Add<Activity>("/activities")
    .Add<Activity("/activities/{id}");

I'm using a backbone app to POST and PUT to my REST Service.

What happens out-of-the-box:

• id property is serialized into the json as "activities/1"
• id property is encoded into route as "activities%2F1"
• ServiceStack gives precedence to the URL based id property, so my string gets the encoded value which is no use to RavenDb directly.

The options I'm aware of:

• Change backbone to post to "/activities" and let the JSON Serialiser kick in
• Change RavenDb ID generation to use hyphens rather than slashes
• Make my Id property parse for the encoded %2F on set and convert to a slash

Both have disadvantages in that I either lose RESTfulness in my API, which is undesirable, or I don't follow RavenDb conventions, which are usually sensible out-of-the-fox. Also, I've a personal preference for having slashes.

So I'm wondering if there are any other options in servicestack that I could use to sort this issue that involve less compromise? Either Serialiser customisation or wildcard routing are in my head....

Answer 1

I have the same problem with ASP.Net WebAPI, so I don't think this is so much a ServiceStack issue, but just a general concern with dealing with Raven style id's on a REST URL.

For example, let's say I query GET: /api/users and return a result like:

[{
  Id:"users/1",
  Name:"John"
},
{
  Id:"users/2",
  Name:"Mary"
}]

Now I want to get a specific user. If I follow pure REST approach, the Id would be gathered from this document, and then I would pass it in the id part of the url. The problem here is that this ends up looking like GET: /api/users/users/1 which is not just confusing, but the slash gets in the way of how WebAPI (and ServiceStack) route url parameters to action methods.

The compromise I made was to treat the id as an integer from the URL's perspective only. So the client calls GET: /api/users/1, and I define my method as public User Get(int id).

The cool part is that Raven's session.Load(id) has overloads that take either the full string form, or the integer form, so you don't have to translate most of the time.

If you DO find yourself needing to translate the id, you can use this extension method:

public static string GetStringIdFor<T>(this IDocumentSession session, int id)
{
  var c = session.Advanced.DocumentStore.Conventions;
  return c.FindFullDocumentKeyFromNonStringIdentifier(id, typeof (T), false);
}

Calling it is simple as session.GetStringIdFor<User>(id). I usually only have to translate manually if I'm doing something with the id other than immediately loading a document.

I understand that by translating the ids like this, that I'm breaking some REST purist conventions, but I think this is reasonable given the circumstances. I'd be interested in any alternative approaches anyone comes up with.