Welcome again to another Logic Apps Best Practices, Tips, and Tricks. In my previous blog posts, I talked about some of the essential best practices you should have while working with Azure Logic Apps. Check out these Logic App tips and tricks!
Today I’m going to speak about another important Best practice, Tips and Tricks that you need to take into consideration while you are designing your business processes (Logic Apps): using other HTTP Methods then POST
#17 using other HTTP Methods then POST
When we think about using the Request trigger inside our Logic Apps – When a HTTP request is received – sometimes people take for granted that they need to use a POST request method. Indeed this is the default HTTP method, but that doesn’t mean that the other HTTP methods are not supported. In fact, we can and should use the most common best practices for REST API while designing our Logic Apps. And like all APIs, the action on our Logic App should be indicated by the HTTP request method that we’re making. The most common methods include GET, POST, PUT, and DELETE.
- GET retrieves resources: The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.
- CRUD: Read
- POST submits new data to the server: The POST method sends data to the server and creates a new resource. The resource it creates is subordinate to some other parent resource. When a new resource is POSTed to the parent, the API service will automatically associate the new resource by assigning it an ID (new resource URI). In short, this method is used to create a new data entry.
- CRUD: Create
- PUT updates existing data: The PUT method is most often used to update an existing resource. If you want to update a specific resource (which comes with a specific URI), you can call the PUT method to that resource URI with the request body containing the complete new version of the resource you are trying to update.
- CRUD: Update/Replace
- DELETE removes data: The DELETE method is used to delete a resource specified by its URI.
- CRUD: Delete
- PATCH updates existing data: The PATCH method is very similar to the PUT method because it also modifies an existing resource. The difference is that for the PUT method, the request body contains the completely new version, whereas, for the PATCH method, the request body only needs to contain the specific changes to the resource, specifically a set of instructions describing how that resource should be changed, and the API service will create a new version according to that instruction.
- CRUD: Update/Modify
To choose different HTTP methods inside the When a HTTP request is received trigger from the Request connector, we need to:
- On the When a HTTP request is received trigger, select the option Add new parameter and then choose the Method parameter
- On the Method parameter we just added, you can find all different types of HTTP methods supported like GET, PUT, POST, PATCH, and DELETE
Besides knowing that we can use different types of HTTP methods in our Logic Apps, it is also important that we can also use, in conjugation with the HTTP methods, Query parameters and/or URI parameters.
Query parameters versus URI parameters
It is very important to know when to use Query Parameter or URI Parameter while designing an API. In a very simple way, we can say that:
- URI parameters (or sometimes called path parameters since they appear inside the URL path) are basically used to identify a specific resource or resources. The URI parameter should be a unique identifier.
- URI means Unique Resource Identifier
- Let’s consider an example where you want to identify an account on the basis of accountId, and in that case, you will be using the URI param.
- GET /accounts/{accountId}
- If we want the employees of a specific account, then it should be something like
- GET /accounts/{accountId}/employees
- Query parameters appear after the path (if any) and start with a question mark character (?)
- Take another example where you want to filter the account on the basis of country, and in that case, you will be using the Query parameter.
- GET /accounts?country=Portugal
- If we want also want to add a limit of results, then it should be something like
- GET /accounts?country=Portugal&limit=10
Whereas Query parameters are used to sort/filter those resources.
Of course, we can and we should, depending on the scenario, also mix URI parameters and Query parameters together! Like, if we want the employees of a specific account but limit the number of results, then it should be something like:
- GET /accounts/{accountId}/employees?limit=10
Know, the important question is: How can we use these URI parameters and QUery parameters inside Logic App?
And to address that, we are going to demonstrate two scenarios using the HTTP GET method. Of course, this will also apply to other HTTP methods.
Working with the HTTP GET method inside Logic Apps using URI Parameters
Well, let’s start with the simple scenario: using URI Parameters!
To use URI Parameters in the When a HTTP request is received trigger, we need to:
- On the When a HTTP request is received trigger, select the option Add new parameter and then choose the Relative Path parameter
- On the Relative Path parameter, we just added, type the URI Parameters, something like:
- /firstname/{fname}/lastname/{lname}
Note: this means that we will have two URI Parameters, first name, and last name
- By doing that, the URI parameters will be automatically tokenized, and we can map to the other operations inside the Business Process implemented.
Now accessing these values is an easy task since they are tokenized. So, if we add a subsequent action, in the picture below a Response action, we can see from the dynamic content floating window all the URI parameters we defined on the When a HTTP request is received trigger. In this case, selecting that token to configure the action properly is just a matter of choosing that token.
Working with the HTTP GET method inside Logic Apps using Query parameters
Working with Query parameters is slightly different and harder to accomplish since they appear after the path and are not tokenized by default like the URI parameters. There isn’t any parameter on the When an HTTP request is received trigger where we can specify them. So, the “When an HTTP request is received” trigger defines the Method as GET (again, that is the same for other HTTP methods).
So, how do we access the Query parameters?
Well, we have to do it using expressions! The Query parameters are “stored” inside the Queries object array.
And to access them, we need to use the following expression:
-
@{triggerOutputs()[‘queries’][‘fname’]}
-
@{triggerOutputs()[‘queries’][‘lname’]}
Assuming the same sample we did on the URI parameters demo. So, basically, it is:
- @{triggerOutputs()[‘queries’][‘<name-of -the-query-parameter>’]
Of course, if we are using the Expression editor, we will skip the @{}, which means that the expression will be:
- triggerOutputs()[‘queries’][‘fname’]
Because these query parameters can be dynamic or optional, it is a good best practice to validate its existence or not… but I will leave that to another Logic App Best practices, Tips, and Tricks!
Stay tuned for the following Logic App Best practices, Tips, and Tricks.
