SDK per language, and that assuming we had a standard for hypermedia. But I
digress...

I have actually taken that approach in my current work - exposing a case
file management system as a REST services.

The idea is to have a generic HTTP (C#) client that works with the REST
idioms as first class citizens of the API - HTTP verbs are methods, it
understands hypermedia, and it works with the appropriate media types
directly in code. The only thing left for a dedicated service SDK is the
definition of link relations and classes that represent the wire format,
such that representations can easily be worked with directly from code.

Let me give an example ...

The generic client is "Ramone" (see
http://soabits.blogspot.dk/2012/04/introducing-ramone-c-library-for-w...
the other entries on the blog).

The SDK defines "const" values for link relations:

class MySDK
{
  public const string CaseFileLinkRel = "mynamespace/casefile";
  public const string AddDocumentLinkRel = "mynamespace/adddoc";

The SDK defines classes that represent the wire format:

class MySDK_CaseFile
{
  public long ID;
  public string Title;
  public string Description;

The SDK defines media codecs (see
http://soabits.blogspot.dk/2012/04/ramone-media-types-and-codecs.html) for
transforming between the wire format and the SDK classes. Ramone has
built-in support for JSON and XML (and HTML) transformations, so often this
is not required.

The service is assumed to present a service document at a well known URL
and the generic client can GET this and use the SDK defined link relations
to lookup the hyper media elements on the service document (see
http://soabits.blogspot.dk/2012/04/ramone-consuming-hyper-media-rest....).

From here the generic client just "follows its nose" using hyper media and
the SDK defined classes.

/Jørn