In the client profiles map to "traits" (which in the java 7 client is interfaces, maybe 8 we'll use default methods). Client is irrelevant but it illustrates the concept really nicely that different profiles indicate what is or isn't present.
So we don't really have "resource types" we have responses that have resources that claim to implement different profiles. This allows you to know what links & fields are or are not there.
I'd like to have a ToC/Nav that lists all profiles, lets you jump around, and indicate rel X on from resource of profile y will likely return profiles a,b or c.
It's very abstract, which can be difficult for consumers to get with thought...so maybe its' better to stick to resource types and collapse profiles around them.
and obv many API's don't use the profile thing explicitly...but implicitly a type could be considered a profile based upon it's "shape", ie the links and fields that are present.
Just spitballing problems here..not even really sure what I'm looking for.
To give you an idea how profiles helps here are two Product resources...that are both products, but also very different:
We’re cleaning out the issue tracker and closing issues that we’ve not seen much demand to fix. Feel free to comment with additional justifications if you feel that this one should not have been closed.
We've settled on using profile link relationship to help define what's available within the resource. https://tools.ietf.org/html/rfc6906
In the client profiles map to "traits" (which in the java 7 client is interfaces, maybe 8 we'll use default methods). Client is irrelevant but it illustrates the concept really nicely that different profiles indicate what is or isn't present.
So we don't really have "resource types" we have responses that have resources that claim to implement different profiles. This allows you to know what links & fields are or are not there.
I'd like to have a ToC/Nav that lists all profiles, lets you jump around, and indicate rel X on from resource of profile y will likely return profiles a,b or c.
It's very abstract, which can be difficult for consumers to get with thought...so maybe its' better to stick to resource types and collapse profiles around them.
and obv many API's don't use the profile thing explicitly...but implicitly a type could be considered a profile based upon it's "shape", ie the links and fields that are present.
Just spitballing problems here..not even really sure what I'm looking for.
To give you an idea how profiles helps here are two Product resources...that are both products, but also very different:
and