In this video we'll show you how to make some basic get requests from something other than
a browser. We will be using the free tool fiddler to demonstrate this. Since fiddler
is able to support multiple platforms we'll be using fiddler to showcase
certain features of PI Web API rather than focusing on a specific language.
When developing your application it's very useful to test out certain HTTP requests to
confirm they're returning the results and headers that you expect. Fiddler allows us
to rule out any language specific problems that may be showing up. Fiddler traditionally uses
an HTTP debugging proxy server application, it's used to capture HTTP and HTTPS traffic
and logs it for you to interpret and dissect. In our case we want to compose HTTP requests
to the PI Web API so we'll disable capture traffic. To compose an HTTP request we can
select the composer tab here. As you can see we can select one of the many HTTP request verbs and
enter the URL we want to connect to. In this case we'll be using the PI Web API endpoint.
We can specify the HTTP protocol version as well as add in the HTTP headers and compose a
body for the request if need be. So let's test out submitting a basic HTTP request. We'll use
the get request and we'll use the main PI Web API landing page for the URL and hit execute.
On the left-hand side we see we have a new entry in our log, we've gotten a 401 response.
To further investigate this response we can select it which will automatically bring us
to the inspectors tab. In the response we see we have a 401 which corresponds to unauthorized
access denied. In our case since we're using Kerberos authentication it's expecting some kind
of authentication method to be included with our request, so let's apply that information.
If we specify the authorization in the request header we should be able to solve to the issue.
Back in the composer tab Fiddler allows us to implement integrated security to our requests
quite easily by selecting the automatically authenticate checkbox under the options tab
in the composer. If we hit execute again we should expect to see a good 200 response now
that we supplied the proper authorization with our request. Looking at the logs we
see the response does in fact have a 200 header and now we can take a look at the response. The
response is in JSON and we see it's the same as what we would see in a browser.
Now that we've successfully submitted to get request and confirm this is properly
working let's try and get something a little more useful. For example I want to get some
information about a particular attribute. Let's take a look at the NuGreen database.
Let's say I wanted to find the fuel gas flow attribute for the boiler b210 element.
Now our job is to construct our URL within fiddler that we can use to get this information
on this attribute. If we navigate through the browser we eventually arrive at this
end point for this particular attribute. Though we don't want to navigate to the browser every
time we want to find out what the URL we need to reach is, so let's take a look at the help
files to see if we construct our Web API endpoint for this information more easily.
For information on the attribute we likely want the attribute controller looking at the possible
actions it seems like get by path is the action we want since we know the name of the AF server,
AF database, element path and attribute name. The help file indicates that we
want to use a get request to the attributes controller endpoint, it also indicates that
if we want to use to get by path action we'll need to use the path URL parameter.
Looking at the syntax information for this in the Web API help files it looks like we
can build this information out. Going back to fiddler we can put this information in the URL
and make a request to the attribute's endpoint. We'll take off the web ID from this URL in the
entry box already and then use question mark path to add the URL parameter. Then we'll type
in the path including the attribute name to the attribute of interest. You'll notice that the URL
highlighted bright red there. This is because cracking process part of the path name has a
space in it spaces aren't allowed in URLs we need to replace this with a percent 20 the URL
encoding for space. Any breaking characters need to be replaced with URL encoding such as space.
Once we've done this we can execute the request and see that we have a good response. We can see
that the JSON information is the same as of what is returned in the browser.
We can see the path is correct as well as the name of the attribute. From the list of
links we can find the link for the value for the attribute. If we copy and paste this in as our new
get request we can execute this request and see the response to the most recent value for this
attribute. You'll notice from the link that we're using the long web ID format to get the value for
this attribute. In addition to the snapshot value for this attribute we can also get the recorded
value for this attribute. Let's take a look at the list of actions on the attributes controller.
We see there's a get value action but we don't see any actions for getting recorded or getting
multiple values. This get multiple action is for getting multiple attributes. So let's go
back and take a look at the URL that's being made for that request in fiddler. We see the
get recorded data is actually hitting the streams controller rather than the attribute controller.
So let's take a look at the streams controller in the help file. Here we can see that we have a get
recorded action. Let's take a closer look at it. If we select this action we can see
that we should use a get request and that will need the web ID of the attribute. Additionally
we have a couple of optional URL parameters such as the start time and the end time. If
you recall from earlier the start time defaults to one day ago and the end time defaults to now.
So let's build a request in fiddler for the recorded value to this attribute.
We've already got the streams and point correctly set so now we just need to change the action from
value to recorded. We'll use a question mark for a URL parameter and we'll specify two hours ago.
We'll leave the end time blank because we want to go until now which is the default
behavior. When we execute this response we see there's only one value for the past two
hours for this attribute. If we try for the past four hours we should see more values.
In this video we introduced Fiddler, a tool that allows us to make HTTP calls to the PI
Web API to test our calls independent of code. We explored making basic get requests specifically
to the home page. We also briefly touched on authorization a topic we'll go over more in
depth in a later video. As well as HTTP response codes. We used the help documentation to build
a more complex get by path call to attributes and used URL parameters to help specify what
information we want from that query. You're now well on your way to using the PI Web API.