Power Automate Flows naming for documentation

I was recently shown this format and I think it's fantastic.  I'm moving all my flows to this Action naming approach:

Format: <Original OOTB name of the Action> | <Verb on Noun> 

Also, see my Flow tips here

Azure Naming Conventions

 My Format (I simplify for smaller companies)

<Company>-<BusinessUnit>-<Region>-<Environment>-<ResourceType>-<Project>-<Instance>

GS-IT-UK-PR-RGP-Treetops-001

GS-HR-US-DV-NSG-Cloud-001

I like to enforce the same length for each part, just because it makes it easier to read in a list.  i.e. Region - Could be the 2 digit country code.  Case consistency is also important. 

Environment is my DTAP environment i.e. DV = Development, TS = Test, AS = Acceptance, PR=Production

Resource Type is the Azure Resource Type e.g. Network Security Group = NSG.   It is worth publishing a list as application services could be app or aps.

Tip: In azure sometime you can't use hyphens or need to use lowercase.  If I am forced, then I keep the same convention but merely abide by the rules of the service.

The key is just keep it consistent.  I find organisation use Tags poorly so with the naming convention, it helps replace the need for Tags or tags can easily be added as it gives the info away in the name.

Microsoft Recommends Azure naming convention:

Another example format:

<4digitApplicationName>-<2digitEnvironment>-apim-<2digitcounter> e.g. taxp-pr-apim-01 or  dvla-dv-appins-01 

I think it is just key to agree a standard format and stick to it.

I 100% ensure naming is consistently followed for resources, it's also useful to have a few tags, but I'm not dogmatic regarding tags.

Tags Examples

Env: Dev

Data Classification: Confidential

Project: Tax Treaties

Designing an API with Web API on Azure

.NET core is great for creating a Web API project to provide an API.
Tip: Swagger is a great tool that has an editor to specify your API.  With the OpenAPI specification for your API, you can generate documentation, or use the code generation feature to generate tests or C# code.
Tip:  Use the Swashbuckle.AspNetCore Nugget package to generate an OpenAPI specification for your API if you use a code first approach.

Do not trust incoming parameters, you must validate.  Always respond with generic header error messages so you don't give away back-end information.  Ensure you log all errors and review them.

Preferred High Level Design I like for Web API projects

The API needs to return Status Codes to allow consumers/clients to know how there operations are doing so I design with these standard HTTP status codes:

CodeCode Status Meaning 200 OK (GET) 201 Created (POST or PUT) 202 Accepted.  Used for long running operations. 204 Resource has been deleted (DELETE) 304 Not Modified 400 Bad Request 401 Not Authorized 403 Forbidden 404 Not Found 422 Entity Validation Issue 429 Too many Requests (Implement at APIM layer only) 500 Internal Error

• The bold codes are the three minimum set of response codes I will use for a simple API.  The next 4 most important are italicized.
• Name resources/EndPoints with nouns and I always use lowercase e.g. /api/customers is better than verb noun which was common a few years ago, e.g., /api/GetAllCustomers  NB!  No verbs in URL naming.
• Keep the URL's simple.
• Always use HTTPS.
• DateTime data is always in UTC.
• Sensitive information must be in the header or body, not in the URL as it is not encrypted.

URL/Resource	GET (read)	POST (create)	PUT (Update)	DELETE (Delete)
/customers	List all customers	Add/created a new customer	Bulk update customers	Bulk Delete or Generally error and don’t implement
/customers/35	Get a specific customer.  Customer 35 is John Doe	NA	Update the John Doe record	Delete the John Doe object/record

HTTP Methods to Support

GET	Return the current value of an object
PUT	Replace or update an object
DELETE	Delete an object
POST	Create a new object.  Return 201 for created and 202 for long running operations.

* PATCH - is also used for updating objects but normally a subsets of existing data

Versioning
API's need to change but there can be multiple client applications consuming my OpenAPI.  We use versioning to ensure I don't break existing implementations.  There are different strategies for versioning API's:

• No versioning:   https://pbeck.co.uk/customers/35
• URI versioning: https://pbeck.co.uk/v2/customers/35
• Query string versioning: https://pbeck/customers/35?version=2
• Header Versioning:  Not in the URL but passed in the header (my preferred option)

APIM has a great implementation for versioning.  Generally, adding optional data is pretty safe for API versioning.  You need to give 3rd parties using your API's time to implement the new version before deprecating and versions.

Tip: Enforce versions are present in the header.  No version return bad request.

JSON
JSON property names SHOULD be camelCased.

Query Params

Allow filtering using query param e.g. https://pbeck.co.uk/customers?firstname='paul'

Allow sorting for the most common properties

DateTime should be in UTC - The pattern for this date and time format is YYYY-MM-DDThh:mm:ss.sTZD. It is recommended to use the ISO-8601 format.  UI does adjustment for local time display.

Paging

Requests must have max return limit e.g. 100 items.  Specifying the limit param if you want to change the size of the dataset to return.

CORS

Cross Origin Request will need to be supported, reply on OAuth for who can use the API.

HATEOAS 

Good way to navigate around your API.  And a principle worth adhering to where possible.  

Authentication and Authorization

API's access should be via OAuth2.0.  It is very easy to hook APIM and underlying App Service (Web API) up to AAD B2C.  Scopes are used for authorization.

Code Review/Quality

"Linting is the automated checking of your source code for programmatic and stylistic errors. This is done by using a lint tool (otherwise known as linter)".   Examples of Linting Tools are Resharper, StyleCop, SonarQube, ...

Security

Always review the OWASP API Security for your API's.

https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
https://owasp.org/www-project-cheat-sheets/cheatsheets/REST_Security_Cheat_Sheet.html

https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md

It's a good idea to also have a WAF in front of your API.