Princeton University · API Governance Rules
Princeton University API Rules
Spectral linting rules defining API design standards and conventions for Princeton University.
9 Rules
error 2
warn 7
Rule Categories
info
operation
response
root
server
Rules
error
operation-has-operationid
Every operation should declare an operationId. Princeton does this 14/14.
$.paths[*][get,post,put,patch,delete]
warn
operation-operationid-verb-case
operationIds follow this API's own convention — a lowercase verb followed by a CapitalCase target (searchCatalog, displayBanner).
$.paths[*][get,post,put,patch,delete].operationId
warn
operation-has-summary
Every operation should carry a summary.
$.paths[*][get,post,put,patch,delete]
warn
operation-has-description
Every operation should carry a description beyond its summary.
$.paths[*][get,post,put,patch,delete]
warn
operation-has-tags
Every operation should be tagged so the contract splits cleanly by resource.
$.paths[*][get,post,put,patch,delete]
warn
response-content-has-example
Every response media type should carry an example. This is the strongest habit in Princeton's contract — 32 of 32 content entries ship one, which is what makes the document usable without a schema section.
$.paths[*][get,post,put,patch,delete].responses[*].content[*]
error
server-is-princeton-operated
Server URLs must resolve under princeton.edu. This is the operator rule: a contract catalogued under Princeton must describe a host Princeton runs, not a vendor platform the institution merely subscribes to.
$.servers[*].url
warn
info-has-contact
info.contact should name a maintainer and a URL. Currently absent — the document is machine-generated from request specs and never had one added.
$.info
warn
root-declares-tags
Root-level tags[] should declare and describe every tag the operations use. Fourteen tags are in use and none are declared, so a consumer gets group names with no definitions.
$