This is a general recommendation of how to name Apigee policies, configurations like keystores, truststores, etc
For more info on these recommendations, check out this doc
feature-{Userstory_Number} or feature-{JIRA_Id}
Example: feature-US1234
{collection}-{version}
Example: /v1/employees, use Employees-v1
SF-{flow}-{version}
Example: SF-Security-v1
{policy-acronyms}-{descriptive-name}
Example: AM-SetTargetHeaders
Note:
The table below has the breakdown of few acronyms for each policy (taken from apigeelint)
Policy | Acronyms |
Access Control | AC AccessControl |
Access Entity | AE AccessEntity |
Assign Message | AM Assign AssignMessage |
Basic Authentication | BA Encode Decode BasicAuth |
Concurrent Rate Limit | CRL |
Extract Variables | EV Extract Vars ExtractVariables |
Flow Callout | FC FlowCallout |
JavaScript Callout | JS JSC JavaScript |
Java Callout | JC Java |
JSON Threat Protection | JTP JSONThreat |
JSON to XML | J2X JtoX JSONtoXML |
Key Value Map | KVM |
LDAP | LDAP |
Message Logging | ML MessageLogging |
Populate Cache | PC PopulateCache |
Lookup Cache | LC LookupCache |
Invalidate Cache | IC InvalidateCache |
Response Cache | RC ResponseCache |
OAuth v1 | OAuthv1 |
OAuth v2 | OAuthv2 |
Python Callout | Python |
Quota | Q Quota |
Reset Quota | RQ |
Raise Fault | RF Fault Raise RaiseFault |
Regular Expression Protection | RE Regex |
SOAP Message Validation | MV |
Generate SAML Assertion | SAML |
Validate SAML Assertion | SAML |
Extension Callout | EC Extension |
Generate JWT | JWT |
Verify JWT | JWT |
Decode JWT | JWT |
Generate JWS | JWS |
Verify JWS | JWS |
Decode JWS | JWS |
Service Callout | SC |
Spike Arrest | SA SpikeArrest |
Statistics Collector | Stats |
Verify API Key | VAK VerifyAPIKey |
XML Threat Protection | XMLTP |
XML to JSON | X2J XtoJ XML2JSON |
XSL Transform | XSL XSLT |
flow.*
Example: flow.app.id
{api}-{descriptive-name}
Example: employees-v1-departments
{api}-{map-name}
Example: employees-v1-targets
{protocol1/2s}-{secure-or-default}-{OptionalDescriptiveName}
Example: https-secure
The virtual host definition will be one time and will not be changed based on requirement
Both certificate creation/update and Virtual host self service is now available, allowing customers to setup mTLS virtual hosts without support requests. The naming convention shown below easily supports certificate updates by changing the values that the reference points to such that the established virtual host need not be changed.
Keystore contain key and certificate chain aliases for use inbound (Client to Apigee) and outbound (Apigee to target)
keystore-inbound-{environment} keystore-outbound-{proxy}-{environment}
Example: keystore-inbound-dev, keystore-outbound-ping-v1-dev
Keystore alias holds key and certificate chain, name the same as the keystore plus the year installed
keystore-inbound-{environment}-{year} keystore-outbound-{proxy}-{environment}-{year}
Example: keystore-inbound-dev-2017, keystore-outbound-ping-v1-dev-2017
Truststore holds certificate chain aliases, one for each client
truststore-inbound-{environment}
Example: truststore-inbound-dev
Truststore alias(es) holds certificate for clients
truststore-inbound-{client}-{environment}-{year}
Example: truststore-inbound-client1-dev-2017
References are pointers to keystores or truststores and are used to facilitate certificate updates
keystore-inbound-{environment}-ref truststore-inbound-{environment}-ref keystore-outbound-{proxy}-{environment}-ref
Example: keystore-inbound-dev-ref refers to keystore-inbound-dev-2017
https://github.com/apigee/api-platform-samples/tree/master/schemas
nice one. We do follow the same. But again it comes to convenience of the company.