Open xogeny opened 6 years ago
I like your initiative.
Related stuff:
MicroTypes implementation is controversial but the concept is very much relevant.
A few comments. I followed the introspected REST discussions in an mailing list at some point. So I was aware of that. Regarding MicroTypes, to be honest the "itch" I'm trying to scratch here is my own and this is too complicated for what I do. Now I'm quite aware that there is a natural tendency for people to say "Oh, that is more complicated than I need" and then realize, in 6 months, that the problem itself was more complicated than they thought and that the "too complicated" solution was, in fact, the appropriate level of complexity for what they are working on. So when I say it is too complicated, I'm stipulating that there is still a 20% chance that I'm wrong and that I will need that functionality. But for now, I just don't see a good ROI for me in pursuing that.
Note, I've called this a "profile" and your reference in the MicroTypes proposal to RFC 6906 prompted me to review that. It seems to me that my "profile" fits exactly what they intend. It doesn't change any semantics, but it does add constraints. So a client without the profile will still have all necessary information but they won't be able to determine additional constraints that are not required to use the API. Furthermore, I have in mind that the profile should be such that it could support multiple media types (although my focus is on Siren for now).
At the moment, the profile lacks any kind of "entry point" URL. Normally, I would say that such a URL could simply be added as an additional property in the
profile.json
file. But I want to first spend some time thinking about how to handle composability (i.e., how to easily knit together multiple specifications to promote their reuse). It wouldn't make sense if each such specification had its own entry point (hence the inadequacy of just adding a new field and the need to think about this further).