Define a mapping between REST resource name and kind/apiVersion

Allows clients to abstractly map user input to generic resource
paths as per docs/api-conventions.md

Extracted from #2000 and supports #1958
Right now the transport code forces a version to be set - it's only on fetches and such that the lookup is relevant.  Kubectl in my other pull returns an error telling you the object needs an API version.


> On Nov 3, 2014, at 5:13 PM, Daniel Smith <notifications@github.com> wrote:
> 
> In pkg/api/meta/restmapper.go:
> 
> > +}
> > +
> > +// RESTMapper exposes mappings between the types defined in a
> > +// runtime.Scheme. It assumes that all types defined the provided scheme
> > +// can be mapped with the provided MetadataAccessor and Codec interfaces.
> > +//
> > +// The resource name of a Kind is defined as the lowercase,
> > +// English-plural version of the Kind string in v1beta3 and onwards,
> > +// and as the camelCase version of the name in v1beta1 and v1beta2.
> > +// When converting from resource to Kind, the singular version of the
> > +// resource name is also accepted for convenience.
> > +//
> > +// TODO: Only accept plural for some operations for increased control?
> > +// (`get pod bar` vs `get pods bar`)
> > +type DefaultRESTMapper struct {
> > +	mapping        map[string]typeMeta
> I am concerned that such "helpful" behavior is going to cause weird stuff like clients asking for most resources in v1beta2 except for minions, which get downgraded to v1beta1 because they're using the wrong term. This could lead to really hard to figure out bugs when some of your objects don't really have all of their fields set because they were transported in a version that you didn't expect.
> 
> —
> Reply to this email directly or view it on GitHub.