Quantum computing in action: IBM's Q experience and the quantum shell game(2)
- UID
- 1066743
|
Quantum computing in action: IBM's Q experience and the quantum shell game(2)
Communicate with the IBM Q experience platformOne of the first things we’ll need to do is to send data to the IBM Q experience platform. Rather than write and rewrite the same code over and over again, I lumped it into a single function called FetchAPIData. This way, other functions like the PerformLogin function only need to pass the relative URL, an HTTP method (post, delete, get etc) and the content (if posting). FetchApiData will take care of the rest.
It begins by adding the relative portion of the URL to the base URL: If we aren’t performing a delete and if we have a User object, it will also pass the User.id as the access_token. When deleting, we pass the User.id as a request header (X-Access-Token) instead of appending the access_token to the URL.
The bulk of the code here is simply building the request message, adding content, and setting request headers. If we get back a success status code, we sent our QResult object correctly, and we are done.
Listing 1. Sending our QResult object1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
| private QResult FetchAPIData(string urlRelativePath,
HttpMethod httpMethod,
HttpContent contentToSend)
{
QResult result = new QResult();
//add auth token if we have a user and we arent deleting
if (User != null && httpMethod !=HttpMethod.Delete)
{
urlRelativePath = urlRelativePath + "&access_token=" + User.id;
}
string url = _baseUrl + urlRelativePath;
Debug.WriteLine("Performing " + httpMethod.ToString() + " to " + url);
if (contentToSend!=null) {
Debug.WriteLine("Sending data " + contentToSend.ReadAsStringAsync().Result);
}
HttpRequestMessage request = new HttpRequestMessage(httpMethod, url);
request.Content = contentToSend;
if (User != null) request.Headers.Add("X-Access-Token", User.id);
using (HttpResponseMessage response = _client.SendAsync(request).Result)
if (response.IsSuccessStatusCode)
{
using (HttpContent content = response.Content)
{
// ... Read the string.
result.Message = content.ReadAsStringAsync().Result;
result.Success = response.IsSuccessStatusCode;
}
} else
{
result.Message = response.ReasonPhrase;
result.Success = false;
}
return result;
}
|
And that’s it! POW!
Now that we have figured out how to communicate with the IBM platform, we need to understand what we must say. Fortunately, it is very simple—there are two phases.
- The first is an exchange of credentials.
- The second is the transmission of the QASM code itself and the receipt of the JSON data representing the result of the quantum code’s execution.
- Phase 1. Exchange credentialsLet’s start with the credentials. For the IBM Q experience platform, we need an API key. To get this key:
- Go to your .
- Click the Regenerate button to have an API key created for you. Figure 2. API token in IBM's Q Experience profile page View image at full size
- Now that we have the API token, we pass it to the web service living at the “/users/loginWithToken” endpoint. The code listing below shows the PerformLogin routine we use to do this.
Listing 2. Passing the API token1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| private QResult PerformLogin()
{
if (_token == string.Empty) throw new Exception("A token is required.");
QResult result = new QResult();
HttpContent content= new StringContent("apiToken=" + _token,
System.Text.Encoding.UTF8,
"application/x-www-form-urlencoded");//CONTENT-TYPE header
result = FetchAPIData("/users/loginWithToken", HttpMethod.Post, content);
if (result.Success)
{
User = JsonConvert.DeserializeObject<QUser>(result.Message);
Debug.WriteLine("Logged in and have UserID: " + User.userid);
} else
{
User = null;
}
return result;
}
|
There is only one trick here: You do not submit JSON data to this endpoint, but rather application/x-www-form-urlencoded data. This took a bit of work to figure out—again, fortunately Fiddler and Wireshark are a great boon when reverse engineering these kinds of things.
If the token is authenticated, we’ll get back a JSON packet similar to this:
Listing 3. Returned JSON packet1
2
3
| "{\"id\":\"XXXXXXXXXXXXXXXXXXXXXXXXXX\",\"ttl\":1209600,\"created\":
\"2017-10-03T14:51:51.918Z\",\"userId\":
\"XXXXXXXXXXXXXXXXXXXXXXXXXXX7999a6\"}"
|
The value of the userId field is used in subsequent calls to the IBM platform. It’s good until the time-to-live (ttl) expires—which, in this simple demonstration code, we ignore. So, in our login step, we deserialize the userId out of resulting message data, and we stash that into our global user object. |
|
|
|
|
|