This is a neat idea; it's sort of an entity-relationship diagram or class diagram for API resources.
In fact, if your audience is familiar with these sorts of diagrams, I wonder if it'd be more readily scannable if you denoted the cardinality of the relationships with the sort of notation you'd see in ERDs or CDs? (Personally, I'm a big fan of Crow's Foot.)
That is intentionally left out of this diagram for two reasons
(1) - That detail is covered by API specs like Swagger
(2) - Two endpoints that return the same resource (of the back of two different operations on the same resource) may return a slightly different format/field. This is up to the developer of the API and best captured in API spces.
By the sounds of it, you'd use this as an overview and use something like Swagger for the actual details of each endpoint.
(For that matter, if you output the diagram in a format that supports hyperlinks like SVG or PDF, you could link from the diagram directly into Swagger.)
[+] [-] adambrenecki|9 years ago|reply
In fact, if your audience is familiar with these sorts of diagrams, I wonder if it'd be more readily scannable if you denoted the cardinality of the relationships with the sort of notation you'd see in ERDs or CDs? (Personally, I'm a big fan of Crow's Foot.)
[+] [-] Bombthecat|9 years ago|reply
I think I didn't see one since like ten years?
[+] [-] suhaschatekar|9 years ago|reply
[+] [-] throwaway2016a|9 years ago|reply
[+] [-] suhaschatekar|9 years ago|reply
(1) - That detail is covered by API specs like Swagger (2) - Two endpoints that return the same resource (of the back of two different operations on the same resource) may return a slightly different format/field. This is up to the developer of the API and best captured in API spces.
[+] [-] adambrenecki|9 years ago|reply
(For that matter, if you output the diagram in a format that supports hyperlinks like SVG or PDF, you could link from the diagram directly into Swagger.)