Field references

I can’t find a firm declaration on this, but I can see it in SwaggerUI, so my question is, is this considered a valid supported way to define that a field in object1 relates to a field in object2.

To say that the photo::album_id field, relates to the album::id field.

So generated code can automatically organize multiple lists of objects.

"definitions": {
	"photo": {
		"type": "object",
		"properties": {
			"id":		{ "type": "integer" },
			"album_id":	{ "$ref": "#/definitions/album/properties/id" }
		},
	},
	"album": {
		"type": "object",
		"properties": {
			"id": { "type": "integer" }
		},
	},
},

If this is valid, or some other way is valid; can an a usage please be added to the examples?

And if not valid then can this or something similar be added?

thanks

[silkentrance]

@gareth-ib you do not design your APIs this way, there is no notion of a foreign key reference. Just make it also an integer and keep in mind that it is actually a reference to an instance of type album.

[gareth-ib]

@silkentrance But data always has the concept of related data. So an API with lots of different objects being passed through it will have a myriad of relational concepts. country, state, city, address, member, profile, anything… So ideally there would be a way to document and generate handlers for that instead of the client programmers needing to learn all the relations that exist in an entire API system. Example a list of 50 profiles, all with a country_id, and separately a unique list of their countries as full objects, which ends up being 2 instances of the country object. As opposed to a client project needing to pre-hard-code relations between objects