Thursday, 21 August 2014

Reading the response message from a PUT request using PHP and cURL

Previously I’ve mentioned that I had to write some PHP to PUT some JSON data to a RESTful web API. After calling curl_exec() to make the PUT request I called curl_getInfo() to retrieve the HTTP status code from the response message, in order to output a success or failure message.

While debugging this function it was sometimes necessary to examine the request message being sent to the web API, to ensure its format was correct. This required setting some additional CURLOPT parameters, as shown in the code below.

1 function callRestAPI($uri, $signature, $json) {
2 $headers = array (
3 "Content-Type: application/json; charset=utf-8",
4 "Content-Length: " .strlen($json),
5 "X-Signature: " . $signature
6 );
7
8 $channel = curl_init($uri);
9 curl_setopt($channel, CURLOPT_RETURNTRANSFER, true);
10 curl_setopt($channel, CURLOPT_CUSTOMREQUEST, "PUT");
11 curl_setopt($channel, CURLOPT_HTTPHEADER, $headers);
12 curl_setopt($channel, CURLOPT_POSTFIELDS, $json);
13 curl_setopt($channel, CURLOPT_SSL_VERIFYPEER, false);
14 curl_setopt($channel, CURLOPT_CONNECTTIMEOUT, 10);
15 curl_setopt($channel, CURLOPT_VERBOSE, true);
16 curl_setopt($channel, CURLOPT_HEADER, true);
17 curl_setopt($channel, CURLINFO_HEADER_OUT, true);
18
19 $response = curl_exec($channel);
20 $request = curl_getInfo($channel, CURLINFO_HEADER_OUT);
21 $statusCode = curl_getInfo($channel, CURLINFO_HTTP_CODE);
22
23 echo $request . "<BR>";
24 echo $response . "<BR>";
25 echo $statusCode . "<BR>";
26
27 curl_close($channel);
28 return $statusCode;
29 }

 

 

 

 

The additions are to set:

  1. CURLOPT_VERBOSE to true in order to output verbose information.
  2. CURLOPT_HEADER to true to include the header in the output.
  3. CURLINFO_HEADER_OUT to true to track the request message.

Then, after executing the PUT request I called curl_getInfo to get information about the PUT request. Specifically I requested the request message string by  using the CURLINFO_HEADER_OUT constant. This provides the request message which can then be output for debugging purposes.

Monday, 18 August 2014

Making a PUT request using PHP and cURL

I recently had to write some PHP to PUT some JSON data to a RESTful web API. My final solution involved reading numerous blog posts to piece together exactly what I needed. Bearing that in mind I decided to document my solution in case it’s useful to others, and for my own future use.

The conventional technique for invoking a PUT operation is to set CURLOPT_PUT to true. However, this option is used to PUT a file, with the file to PUT being set with CURLOPT_INFILE and CURLOPT_INFILESIZE. Using this approach involves writing your JSON data to a file first, and removing the file after the operation. Aside from the inefficiency of this approach, functions such as tmpfile(), fwrite() and fseek() are not always supported in some environments.

The standard solution is to set CURLOPT_CUSTOMREQUEST to “PUT” in order to specify the request type, and then set the CURLOPT_POSTFIELDS to the JSON data you want to PUT. In addition, you must set CURLOPT_RETURNTRANSFER to true in order to return the transfer value as a string, rather than it being output directly by curl_exec(). This is a well documented solution, most notably by LornaJane.

However, this solution needed extending in order to enable communication over SSL. In addition, I needed to append some custom header information to the request in order to support the authentication required by the web service. My solution is shown below.

1 function callRestAPI($uri, $signature, $json) {
2 $headers = array (
3 "Content-Type: application/json; charset=utf-8",
4 "Content-Length: " .strlen($json),
5 "X-Signature: " . $signature
6 );
7
8 $channel = curl_init($uri);
9 curl_setopt($channel, CURLOPT_RETURNTRANSFER, true);
10 curl_setopt($channel, CURLOPT_CUSTOMREQUEST, "PUT");
11 curl_setopt($channel, CURLOPT_HTTPHEADER, $headers);
12 curl_setopt($channel, CURLOPT_POSTFIELDS, $json);
13 curl_setopt($channel, CURLOPT_SSL_VERIFYPEER, false);
14 curl_setopt($channel, CURLOPT_CONNECTTIMEOUT, 10);
15
16 curl_exec($channel);
17 $statusCode = curl_getInfo($channel, CURLINFO_HTTP_CODE);
18 curl_close($channel);
19 return $statusCode;
20 }

The important additions are that I set:

  1. CURLOPT_SSL_VERIFYPEER to false to stop cURL from verifying the peer’s certificate, thus enabling communication over SSL. By default this value is true, and you are meant to set CURLOPT_CAINFO to specify the file holding the certificate to verify the peer with. I opted for stopping cURL from verifying the peer’s certificate in the interests of simplicity.
  2. CURLOPT_HTTPHEADER to an array of HTTP header fields, containing the data required by the web service, including an authentication parameter.

In addition, after executing the PUT request I called curl_getInfo to get information about the PUT request. Specifically I requested the status code of the operation using the CURLINFO_HTTP_CODE constant. This provides the HTTP status code contained within the response message, which is then returned to the calling function, so that an appropriate message can be output.

Monday, 4 August 2014

Delivering and consuming media from Azure Media Services

Previously I’ve summarised how to use the Azure Media Encoder to encode uploaded media for delivery to client apps. To do this you create a media processing job that enables you to schedule and automate the encoding of assets.

In this blog post I’ll summarise how Azure Media Services content can be downloaded, or directly accessed by using locator URLs. For more information about locator URLs see my previous blog post. Content to be delivered can include media assets that are stored in Media Services, or media assets that have been encoded and processed in different ways.

Delivering media

There are a number of approaches that can be used to deliver Media Services content:

  • Direct download from Azure Storage
  • Access media in Azure Storage
  • Stream media to a client application
  • Send media content to another application or to another content provider.

Media content can be directly downloaded as long as you have the Media Services credentials for the account that uploaded and encoded the asset. Content can be downloaded by creating a shared access signature (SAS) locator, which contains a URL to the asset that contains the requested file. The URL can then be used by anyone to download the asset.

Alternatively, you may want to give users access to content stored in Azure Storage. To do this you must create a full SAS URL to each file contained in the media asset. This is achieved by appending the file name to the SAS locator.

Media Services also provides the means to directly access streaming media content. This is accomplished by creating an on-demand origin locator, which allows direct access to streaming content. With on-demand origin locators, you build a full URL to a streaming manifest file in an asset. You then provide the URL to a client application that can play streaming content.

Content can also be delivered by using a Content Delivery Network (CDN), in order to offer improved performance and scalability when streaming media. For more information see How to Manage Origins in a Media Services Account.

When streaming media using on-demand origin locators you can take advantage of dynamic packaging. When using dynamic packaging, your video is stored in one encoded format, usually an adaptive bitrate MP4 file set. When a video player requests the video it specifies the format it requires, and the Media Services Origin Service converts the MP4 file to the format requested by the player. This allows you to store only one format of your videos, therefore reducing storage costs. For more information about the Origin Service see Azure Media Services Origin Service.

The following diagram shows a high-level overview of the media delivery process that we used in the Building an On-Demand Video Service with Microsoft Azure Media Services project.

IC721580

Client apps request media through a REST web interface. The Contoso web service queries the Content Management System, which returns the URL of the media asset in Azure Storage. The media asset could be a single media file, or a manifest file which references multiple media files. The client application then requests the URL content from the Origin Service, which processes the outbound stream from storage to client application. For a code walkthrough of this process see Browsing videos, Playing videos, and Retrieving recommendations.

You can scale Media Services delivery by specifying the number of on-demand streaming reserved units that you would like your account to be provisioned with. For more information see Scale a Media Service.

Summary

This blog post has summarised how Azure Media Services content can be downloaded, or directly accessed by using locator URLs. Content to be delivered can include media assets that are stored in Media Services, or media assets that have been encoded and processed in different ways.