api-strategy
api-strategy copied to clipboard
equinor
Equinor API Strategy
Consider stating explicitly in the API strategy that it applies not only to applications and data, but also IT services like infrastructure and middleware.
- API backends secured with OAuth2 and OIDC - Authentication and authorization fully handled in backend - Set up token validation rules in APIM, as an additional layer of protection...
Perhaps, API Versioning constraints shall be introduced? Like COM "Interfaces must be immutable" or, at least, backward-compatible? In general, guidelines on API lifecycle may be needed.
Swagger: https://equinor.slack.com/files/U02JL08ES/FHL27LE95/wellcomapi-swagger.json Api site: https://readwebapidbr.azurewebsites.net/swagger/index.html
https://equinor.slack.com/files/U02JL08ES/FHKQBTZRD/dbrcloudapi-swagger.yaml Kan også sees i APIM (Log in and subscribe): https://api-dev.portal.equinor.com/docs/services/version1/operations/getRigs
Some "common sense" constraints on generalizing the interfaces may be put here. Often it is difficult to predict usage of the interface outside the current scope (except obvious/trivial cases). Generalized...
"API Design/Design Principles/API First", first bullet. What is a "standard specification language"? Open API Specification? Isn't it too much REST specific? What about Non-REST APIs?
Ideally - all weakly typed data must be fixed, or, at least, documented. Must conform to eventual immutability/compatibility constraints . That is, not only formal interface, but semantics as well...
@Qif-Equinor and others have proposed to include guidelines on resource naming cardinality in the API Strategy. From Qiang's PR: ##### Resource naming A resource name should clearly indicate the cardinality...
@arildeikeland has proposed that the API Strategy contains guidelines on rest verbs