Allow embedding to rely on an interface

[smyrman]

Today embedding is done by checking if a schema.FieldValidator (or fallback validator stored within a resource's index) type asserts to &schema.Resource or &schema.Connection. This makes it hard to write custom reference Validators and have them work just as well as the default ones. This could sometimes be useful when you have very application specific validation requirements for linked resources.

One solution to this, cold be to let schema.Resource and schema.Connection implement an interface each that let's you lookup the linked resource. E.g.

type ReferenceType interface {
        LinkedResource() query.Resource
}
type ConnectionType interface {
        LinkedResource() (field string, query.Resource)
}

An alternate (and faster) implementation would be to return the Path instead of the query.Resource, but that might be less flexible, e.g. if we wanted to support exotic use-cases such as "external resources".

[smyrman]

As an example of the latter use-case, and "external resource" could be a resource (e.g. "users") that should be fetched from a different REST-API that we have somehow managed to wrap into a query.Resource compatible type.

[rs]

Sounds like a good idea.

[smyrman]

There is one challenge I don't know how to solve (with or without this change) and that is how to support embedding if a schema.Reference is member of a nested type such as a schema.Dict or schema.Array....

"x": {
    Validator: &schema.Dict{
        ValuesValidator: &schema.Reference{},
    },
},
"y": {
    Validator: &schema.Array{
        ValuesValidator: &schema.Reference{},
    },
},

Today I believe it only works for subschemas via the field.Schema attribute:

rest-layer/schema/query/projection_evaluator.go

Line 67 in b0185e6

if def != nil && def.Schema != nil {

With regards to #77 that's probably not the best way to deal with this. Maybe another interface to inform about children?

type NestedType interface {
    Children() schema.Fields
}

Sub-schemas (i.e. schema.Object) would simply returns it's Fields instance, where as Arrays and Dicts would use a wildchar "*" maybe. For types without Fields (e.g. schema.Dict and schema.Array), a field could be created ad-hock, or the validators could actually change to replace the ValuesValidator with a Field attribute...

This would make the REST embedding syntax for nested "arbitrary fields" function like this:

fields=x{*},y{*}

What about GraphQL?

[smyrman]

Should probably deprecate schema.ReferenceChecker, and use query.Resource as the inteface for item extraction.

rest-layer/schema/query/projection_evaluator.go

Line 12 in 48c11e5

type Resource interface {

Otherwise see in light of #77, #192, #194.