Home

Developer Pre-review Checklist for Push to Dev Review

• The code has been checked into GitHub, into the correct feature branch (standard PR process).
• A GitHub Pull Request is made to have the API reviewed.
• Run the current release of mulint and review any warnings or errors.
• Verify that .project and .classpath files are not in GitHub (mulint does validate that .gitignore ignores them).
• MUnit tests exist for as appropriate for API functionality.
• The API adhere to the security standards (including: TLS 1.2 is used for all communication. Both REST and SOAP integrations).
  • client_id and client_secret should be enabled for all Experience APIs, even in dev. With the latest upgrade to Anypoint we are able to promote policies through environments. So development should have ALL policies applied to them so we can easily promote and developers have tested things completely
• The API has been documented in Exchange.
  • The documentation should also list any dependencies they have on other APIs. (Ex: rollout-coordinator-process-api depends on wstrl-system-api, etc)
• The API is published in Exchange and API Manager has been configured for the API.
• The API has had all identified policies applied to it. - Done by C4E member
  • If this is an Experience API then the following policies should be applied:
    • Client ID enforcement
    • CORS Policy
  • If this is a Process or System API then the following policies should be applied (only for POST and PUT):
    • JSON Threat Protection (If the inbound / outbound payloads are JSON) - json threat
    • XML Threat Protection (If the inbound / outbound payloads are XML) - xml threat
• We should only communicate over HTTPS unless there is a compelling reason (legacy service, etc.).
• Run the project in Anypoint Studio and try a GET (if implemented). Stop the project.
• Run a mvn clean package on the project from command line, verify all tests pass and there are no errors.
  • You may need to pass in arguments for mule.env and https.port (mvn clean package -Dmule.env=local -Dhttps.port=8443)
• Flows and flow components should be named accordingly so that it can be quickly determined what it is doing (Transform Message = bad, Transform SOAP Request, Create SOAP Request = good)
• DataWeave has been placed in external files and not done inline.
• Use parameterized SQL to avoid SQL injection.
• It is highly suggested that the API use the common-dataweave project / jar for transformations.
• Validate that transform types match RAML types on response.
• A Team City build configuration should be created for the API that is being reviewed.