I'm using "Azure Media Encoder" to encode the video uploaded for streaming using below REST API call
GET https://wamsbayclus001rest-hs.cloudapp.net/api/MediaProcessors()?$filter=Name%20eq%20'Azure%20Media%20Encoder' HTTP/1.1
DataServiceVersion: 1.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
Accept: application/json
Accept-Charset: UTF-8
Authorization: Bearer http%3a%2f%2fschemas.xmlsoap.org%2fws%2f2005%2f05%2fidentity%2fclaims%2fnameidentifier=amstestaccount001&urn%3aSubscriptionId=f7f09258-6753-4ca2-b1ae-193798e2c9d8&http%3a%2f%2fschemas.microsoft.com%2faccesscontrolservice%2f2010%2f07%2fclaims%2fidentityprovider=https%3a%2f%2fwamsprodglobal001acs.accesscontrol.windows.net%2f&Audience=urn%3aWindowsAzureMediaServices&ExpiresOn=1421675491&Issuer=https%3a%2f%2fwamsprodglobal001acs.accesscontrol.windows.net%2f&HMACSHA256=9hUudHYnATpi5hN3cvTfgw%2bL4N3tL0fdsRnQnm6ZYIU%3d
x-ms-version: 2.11
Host: wamsbayclus001rest-hs.cloudapp.net
I got a suggestion to use "Media Encoder Standard" instead of "Azure Media Encoder" to reduce the encoding cost. Is there any REST API call for Media Encoder Standard ? I did't find any.
GET https://media.windows.net/API/MediaProcessors HTTP/1.1
Content-Type: application/json;odata=verbose
Accept: application/json;odata=verbose
DataServiceVersion: 3.0
MaxDataServiceVersion: 3.0
x-ms-version: 2.11
Authorization: Bearer
will return a list of all supported media processors which you can use. Select appropriate based on your job.
https://msdn.microsoft.com/en-us/library/azure/hh973617.aspx is a Azure Media Services REST API reference page
https://msdn.microsoft.com/en-us/library/azure/hh973619.aspx contains various task presets for individual encoders
Related
I am trying to use SAPUI5 in a SPA to display data from a TEIID/Wildfly ODataV4 service. When SAPUI5 ODATA V4 data model is bound to the service, I run into several errors. I thereby connect via proxy (grunt-connect-proxy2) to the odata service. Basic Auth works. The metadata file above the marked service folder in the attached image (screenshot1) is the actual metadata file of the service which, as you can see, is loaded correctly. So no CORS issue or authorization issue.
Screenshot1
The issue seems to be related to an CSRF Token request as far as I understand. Seems that Teiid/Wildfly is not answering the CSRF Token fetch request. Is there a way to configure Wildfly to answer the request or alternatively a way to disable CSRF requests for the odata V4 model? I have seen such an option in the constructor of the odata V2 model. How could a working configuration look like?
The following is a screenshot from the browser log:
I observed a further issue, from which I do not know if it is related to the previous one (there is also a X-CSRF-Token: Fetch involved), or if a have something more missing somewhere. The second issue happens when I use an aggregation binding to bind a odata collection to a sapui5 list. The response looks like
Request URL: http://localhost:9001/odata4/svc/my_nutri_diary/$batch
Request Method: POST Status Code: 406 Not Acceptable Remote Address:
[::1]:9001 Referrer Policy: no-referrer-when-downgrade Response
Headersview source access-control-allow-credentials: true
access-control-allow-origin: http://localhost:9001 cache-control:
no-cache, no-store, must-revalidate connection: close
content-encoding: gzip content-length: 125 content-type:
application/json;odata.metadata=minimal date: Mon, 12 Nov 2018
20:04:30 GMT expires: 0 odata-version: 4.0 pragma: no-cache server:
WildFly/11 x-powered-by: Undertow/1 Request Headersview source Accept:
multipart/mixed Accept-Encoding: gzip, deflate, br Accept-Language: de
Authorization: Basic SU1TVXNlcjpJTVM0Zm9ydW0l Connection: keep-alive
Content-Length: 329 Content-Type: multipart/mixed;
boundary=batch_id-1542053070786-11 Cookie: sidebar_collapsed=false;
cycle_analytics_help_dismissed=1;
__utmz=111872281.1539128843.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none); __utma=111872281.767670437.1539128843.1541866362.1541870562.42 DNT: 1 Host: localhost:9001 MIME-Version: 1.0 OData-MaxVersion: 4.0
OData-Version: 4.0 Origin: http://localhost:9001 Referer:
http://localhost:9001/ User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS
11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko)
Version/11.0 Mobile/15A372 Safari/604.1 X-CSRF-Token: Fetch
X-Requested-With: XMLHttpRequest Request Payload
--batch_id-1542053070786-11 Content-Type:application/http Content-Transfer-Encoding:binary GET Profile?$skip=0&$top=100 HTTP/1.1
Accept:application/json;odata.metadata=minimal;IEEE754Compatible=true
Accept-Language:de
Content-Type:application/json;charset=UTF-8;IEEE754Compatible=true
--batch_id-1542053070786-11--
Thanks for your advice!
Best regards,
Christoph
Further note regarding search for a workaround: As I am currently searching for a workaround to be able to use the odata.v4 model, I found the following blog post:
https://blogs.sap.com/2015/08/05/disable-csrf-token-for-odata-calls-using-sap-netweaver-gateway/
However, the approach does not seem to work for the odata.v4 model as it has a different interface. There is no setHeaders() function to set custom headers on the datamodel. I therefore tried to set the header up via
$.ajaxSetup({headers: {'X-Requested-With': 'X'}});
Unfortunately, this also does not work. If someone has the odata.v4 Model running with TEIID or Olingo v4 it would be great if he could give me a feedback on how he had worked around this issue.
I am trying to perform a GET-Request to the ec2-Endpoint https://ec2.eu-central-1.amazonaws.com/?Action=DescribeInstances&Version=2016-11-15 in order to get a list of all ec2 instances within my aws account (in eu-central-1 region). Unfortunately the response's content is formatted in xml. Is there a chance to change the format of the response to json?
I've already set the GET-Request's Accept-Header to "application/json" but without success.
If I query the iam-endpoint https://iam.amazonaws.com/?Action=ListUsers&Version=2010-05-08 with the same Accept-Header the response's content is being delivered properly in json string format.
These are the headers for the ec2-query (not working):
GET /?Action=DescribeInstances&Version=2016-11-15 HTTP/1.1
Host: ec2.eu-central-1.amazonaws.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
X-Amz-Date: 20180706T091958Z
Authorization: <valid AWS4 authorization header>
Cache-Control: no-cache
Postman-Token: 69c8f349-95b5-4e9d-991c-5ce2a55b0cbe
And the headers of my iam-query (working):
GET /?Action=ListUsers&Version=2010-05-08 HTTP/1.1
Host: iam.amazonaws.com
Accept: application/json
Content-Type: application/x-www-form-urlencoded
X-Amz-Date: 20180706T092222Z
Authorization: <valid AWS4 authorization header>
Cache-Control: no-cache
Postman-Token: ad86f2ae-870c-4289-a9d3-1f2ad9082c8f
Executing aws cli tools command aws ec2 describe-instances lists all instances in json format, so I think there should be a way to achieve this with a GET-request.
Thank you very much for your help.
Probably too late, but might help others.
I also tried to get json output from DescribeInstances without luck.
It seems to be impossible at the moment, since even aws cli receives it in xml and then converts it to json. You can see it using --debug flag:
aws ec2 describe-instances --debug
I'm writing application in which i upload video, encode it, and then i need to expose a link to encoded video. One of the steps is to create AssetDeliveryPolicies and link it to Asset, i tried to do that, but to my surprise i don't see such entity as AssetDeliveryPolicies on that endpoint:
https://wamsamsclus001rest-hs.cloudapp.net/api/AssetDeliveryPolicies
Do anybody have tried to do something like that? I'm not sure whether i'm doing something wrong or it is already deprecated and handled in some other way.
Create an AccessDeliveryPolicy
POST https://media.windows.net/api/AssetDeliveryPolicies HTTP/1.1
Content-Type: application/json
DataServiceVersion: 1.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
Accept: application/json
Accept-Charset: UTF-8
Authorization: Bearer [token here]
x-ms-version: 2.11
x-ms-client-request-id: [guid here]
Host: media.windows.net
{"Name":"Clear Policy",
"AssetDeliveryProtocol":7,
"AssetDeliveryPolicyType":2,
"AssetDeliveryConfiguration":null}
Link an AssetDeliveryPolicy to an Asset.
POST https://media.windows.net/api/Assets('nb%3Acid%3AUUID%3A86933344-9539-4d0c-be7d-f842458693e0')/$links/DeliveryPolicies HTTP/1.1
DataServiceVersion: 1.0;NetFx
MaxDataServiceVersion: 3.0;NetFx
Accept: application/json
Accept-Charset: UTF-8
Content-Type: application/json
Authorization: Bearer [token here]
x-ms-version: 2.11
x-ms-client-request-id: [new guid here]
Host: media.windows.net
{"uri":"https://media.windows.net/api/AssetDeliveryPolicies('nb%3Aadpid%3AUUID%3A92b0f6ba-3c9f-49b6-a5fa-2a8703b04ecd')"}
Where nb%3Acid%3AUUID%3A86933344-9539-4d0c-be7d-f842458693e0 is the URL Encoded value of AssetId and nb%3Aadpid%3AUUID%3A92b0f6ba-3c9f-49b6-a5fa-2a8703b04ecd is the URL Encoded value of the AccessDeliveryPolicy Id.
Source
When using the OneDrive REST API to upload files, the content of some files with a .png extension is automatically converted to JPEG. I'm able to reproduce the problem with both documented upload methods.
Sample png files:
http://www39.zippyshare.com/v/59255310/file.html
http://www2.zippyshare.com/v/11270772/file.html
For reference the shortened requests:
PUT method
PUT https://apis.live.net/v5.0/folder.<removed>/files/i2.png HTTP/1.1
Pragma: no-cache
<removed - no Content-Type header>
Content-Length: 33579
Host: apis.live.net
When the Content-Type in the header of the PUT request is set to application/octet-stream the following error is returned:
HTTP/1.1 415 Unsupported Media Type
Server: Live-API/19.7.925.4009 Microsoft-HTTPAPI/2.0
<removed>
{
"error": {
"code": "request_body_invalid_media_type",
"message": "The Content-Type header 'application/octet-stream' isn't supported."
}
}
POST method
POST https://apis.live.net/v5.0/folder.<removed>/files HTTP/1.1
Content-Type: multipart/form-data; boundary=735b1931-a2bb-4970-8142-373848528fcb
<removed>
Content-Length: 33767
Host: apis.live.net
--735b1931-a2bb-4970-8142-373848528fcb
Content-Disposition: form-data; name="file"; filename="i2.png"
Content-Type: application/octet-stream
.PNG<removed>
--735b1931-a2bb-4970-8142-373848528fcb--
Other OneDrive APIs
The problem does not happen with the API (skyapi.onedrive.live.com/API/2) Microsoft is using on the OneDrive website and in the Windows desktop client (skydrive.exe).
OneDrive developers:
Instead of returning a 415 error in the PUT request, would it be possible to support requests where the Content-Type: application/octet-stream header is set? In this case the data should be left as is without doing any data conversion. Thank you.
This is documented behaviour as per http://msdn.microsoft.com/en-us/library/dn659726.aspx (see the first note under uploading).
If you want to disable conversion, you can set downsize_photo_uploads=false in your query string.
How to use #HEAD in jax-rs using Jersey API or any other jax-rs API ? please give me sample.
You don't need to explicitly support HEAD as Jersey will automatically support it. Here is what Jersey's the documentation says:
By default the JAX-RS runtime will automatically support the methods HEAD and OPTIONS, if not explicitly implemented. For HEAD the runtime will invoke the implemented GET method (if present) and ignore the response entity (if set). For OPTIONS the Allow response header will be set to the set of HTTP methods support by the resource. In addition Jersey will return a WADL document describing the resource.
(Source: https://eclipse-ee4j.github.io/jersey.github.io/documentation/latest/user-guide.html#d0e2157)
Here is some dirt simple code illustrating how to send a HEAD request using the Jersey client:
ClientConfig config = new DefaultClientConfig();
Client client = Client.create(config);
WebResource resource = client
.resource("http://localhost:8080/services/echo?message=Hello+World");
ClientResponse response = resource.accept(
MediaType.APPLICATION_JSON).head();
System.out.println(response);
Note the use of the head method. The response object returned contains lots of useful information, like the content type produced, the status code of the request, etc etc. The example can be translated to other client library types, but basically you send exactly the same request as you would with a GET, but with the HEAD method instead. Heres an example of the request that would be sent via a browser tool like 'REST Console':
Request
HEAD /services/echo?message=Hello+World HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 0
Accept: application/json
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: JSESSIONID=vWu5N2H8Y+P9SuZKWxhpIdgP.undefined
Response:
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json
Content-Length: 0
Date: Fri, 03 May 2013 05:42:20 GMT