Trying to call Form recognizer API for Invoice analyzer and try to pass multipart file with request like below,
curl -v -i POST
"https://xxx.cognitiveservices.azure.com/formrecognizer/v2.1/prebuilt/invoice/analyze/formrecognizer/v2.1/prebuilt/invoice/analyze"
"Content-Type: multipart/form-data"
-F "form='C:\Users\User\Desktop\Receipt.pdf';type=.pdf"
-H "Ocp-Apim-Subscription-Key: xxxa3fb3553dd81bd1f4c5b1xxx"
This giving me error as "error":{"code":"404","message": "Resource not found"}}
What i am doing wrong? Any help will be appreciated.
Currently Azure Form Recognizer Analyze Invoice input document must be of one of the supported content types - 'application/pdf', 'image/jpeg', 'image/png' or 'image/tiff'. Alternatively, use 'application/json' type to specify the Url location of the document to be analyzed. Please check the values you provide for the Azure form Recognizer resource and input data requirements.
404 states: The server has not found anything matching the Request-URI.
Related
I am using the forms recognizer preview. I have already trained a model using the documentation provided in this documentation.
https://learn.microsoft.com/en-us/azure/cognitive-services/form-recognizer/quickstarts/curl-train-extract
However when I attempt to execute the curl command to analyze the request; I get an error message indicating:
{"error":{"code":"UnsupportedMediaType","message":"In case of HTML form data, the multipart request must contain a document with a media type of - 'application/pdf', 'image/jpeg' or 'image/png'."}
The file I am uploading is a PDF (I've verified the response headers). I have also indicated this in the curl request as:
curl -X POST "https://[omitted]/formrecognizer/v1.0-preview/custom/models/[omitted]/analyze" -H "Content-Type: multipart/form-data" -F "form=[omitted];type=application/pdf" -H "Ocp-Apim-Subscription-Key: [omitted]"
Could you please share your PDF document, The issue may be with the PDF document containing different media types.
Just resolved it. Change the Content-Type to 'application/pdf' and in the body, send through the contents of the PDF, it doesn't seem to work with just the path.
I'm trying to upload a video using multipart linkedin v2 asset upload api. After uploading all parts successfully. When i'm trying to complete the upload, it throws 401 error response.
Request
curl -v -X POST -H "Content-Type:application/json" -H "X-RestLi-Protocol-Version:2.0.0" "https://api.linkedin.com/v2/assets?action=completeMultiPartUpload&oauth2_access_token=xxxx" --data '{"completeMultipartUploadRequest":{"metadata":"abcdhjf lmmfk45322jnmdfmndk","partUploadResponses":[{"httpStatusCode":200,"headers":{"ETag":"d8b472e8f16603b7b6ca4a0cbb1653eb"}},{"httpStatusCode":200,"headers":{"ETag":"30a52d0e398863a1e47418c468ec8929"}},{"httpStatusCode":200,"headers":{"ETag":"92431e62823450eeb0def68024872882"}},{"httpStatusCode":200,"headers":{"ETag":"e6a9c6eacffd9d1f2532eac83d3208e3"}},{"httpStatusCode":200,"headers":{"ETag":"e6bfcf0807a71d63b48d58545101852c"}},{"httpStatusCode":200,"headers":{"ETag":"d355aa0d72c6787e9bfe5f66967c12ba"}},{"httpStatusCode":200,"headers":{"ETag":"1bc89f2c688b6abb970862a3326474fe"}},{"httpStatusCode":200,"headers":{"ETag":"9d89fff03e36ea12e4f0c842d3bb5431"}},{"httpStatusCode":200,"headers":{"ETag":"30f10c2baab55a0185eb396a06b86d39"}},{"httpStatusCode":200,"headers":{"ETag":"e1dc1eac95ab7ef51e38aeb7702b7e4f"}},{"httpStatusCode":200,"headers":{"ETag":"2365a3d1334953209611aef89739e751"}}],"mediaArtifact":"urn:li:digitalmediaMediaArtifact:(urn:li:digitalmediaAsset:abc123,urn:li:digitalmediaMediaArtifactClass:aws-userUploadedVideo)"}}'
Response
{"message":"com.linkedin.vector.assetmanager.logic.LogicLayerException: Enforced Tenant ACL result: false, for Tenant urn:li:digitalmediaTenant:5 and Method complete_multipartUpload","status":401}
Can anyone help to resolve this?
I had this issue and reached out to LinkedIn. They just told me they fixed it on their end, and when I try to complete my multipart upload requests now, it's working properly.
What is the expected value for Metadata field in Complete Multi-Part Upload? Is it the uploaded media ID or any token? If token then from where can we generate this token.
I configured a REST webservice (a Spring Boot webapplication) on WSO2 AM and used the default /* mapping for resources. My webservice takes an assignee (text) and file parameters.
When I perform the calls, I've noticed that request parameters are not forwarded (HTTP Headers are) to the backed services. For example:
curl -i -X POST -H "Content-Type: multipart/form-data" -H "X-PD20-BillingSubscriptionId: e87d4400-b05f-4f40-9c39-06ae4d28cf4d" -H "Authorization: Bearer rrxRV5F6jdkSBcEPXv7I1yFl2x8a" -F "documentFile=#src/test/resources/sample-files/test-fea-1firma.pdf" -F "assignee=bla.bla#gmail.com" http://api.linksmt.it:8280/fea/1.0.0/signRequest
As you can see, It's a form that posts 2 fields, one of them being a file and another a simple text field.
The call is succesfully forwarded to the backed service but without the actual fields values (the headers instead are correctly passed, though their keys are lower-cased, that is "X-PD20-BillingSubscriptionId" is passed as "x-pd20-billingsubscriptionid").
Any hint on why is this happening?
Thanks
Ok, the problem was the same as described in multipart form data file upload using WSO2 API manger ? and I had to uncomment the declarations for
within the $WSO2_AM/repository/conf/axis2/axis2.xml file (and restart the server).
I am learning REST API and URI design and I have found one here:
https://raw.githubusercontent.com/JeanVEGA/MI-MPR-DIP-Admission/master/examples/requests.sh
I have a few questions.
There is for example:
User.resetPassword, anonymous by User's {email}
curl -i -X POST http://localhost:9090/admission/services/user/person/email:{email}/reset_password
I do not understand construction email:{email}... what does it mean? It means that if I have String path param, I need to do it in this way?
The similar is here:
Term.get
curl -i -H "Accept: application/json" -H "X-CTU-FIT-Admission-Session: [session identifier from User.identity]" http://localhost:9090/admission/services/term/dateOfTerm:{dateOfTerm}/room:{room}
room:{room} - Is this because room should be for example 123ABC? So it is not a number so it need to be written in this way?
And my last question:
User.resetPassword for User by Admission Code, send notification to User's Email and this {email}
curl -i -H "X-CTU-FIT-Admission-Session: [session identifier from User.identity]" -X POST http://localhost:9090/admission/services/user/admission/{admissionCode}/person/email:{email}/reset_password
My poiont of question is "reset_password" ... I thought due to right design principles that no verb should be in URI... because if the verb is in URI, I thought that it means that resource is actually an operation.
That url can be only a resource identifier. So this is an url template which waits a unique email address as a parameter. A filled in template should look something like this:
./person/email:my#email.adr/reset_password
note:
The reset_password is not a valid REST resource (it describes a service not a resource) and the POST method is mostly for resource creation (not for update or partial update). Real REST requests look like this:
PUT ./person/email:{email}/password "newpass"
PUT ./person/{id}/password "newpass"
PUT ./person/email:{email}/identification_factors/password "newpass"
PATCH ./person/email:{email}/identification_factors {password: "newpass"}
and so on...
I know HTTP PUT is an idempotent request that store something at a specific URI, according to the definition (quoted from the rfc)
The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
But what is the definition of 'enclosed entity'? It doesn't seem possible for me to send form data (like for HTTP POST request) over. What about sending representation of the entity via JSON/XML or in other serialization formats?
In short, how does one send a HTTP PUT request over to store/update info at a specific URI then?
In REST you have:
GET - retrieve resource
POST - create new resource
PUT - update existing resource
DELETE - delete resource
So the PUT verb is used to update an existing resource on the server. Depending on the client there are various ways of sending a PUT request. For example with jquery AJAX:
$.ajax({
type: 'PUT',
url: '/products/123',
data: { name: 'new product name' }
});
The enclosed entity is the payload data contained in the HTTP message body (after any transfer encodings have been removed.) If you're having trouble sending the message body then it could be that you've forgotten to include a Content-Length header - that's one of two ways to indicate that the HTTP message has a body.
PUT is the same as POST except for this semantic difference: With POST the URI identifies a resource that will handle the entity, such as a servlet. With PUT the URI identifies the entity itself, for example a file that will be created/replaced with the contents of the entity body.
So a HTTP PUT request is often issued to replace the currently stored resource at a given URI. For example, there's a book stored at https://example.org/book/1 where the data can be representated in JSON as follows,
$ curl --request GET https://example.org/book/1
{
"title": "Stackoverflow Compilation Book 1",
"year": 2019
}
Suppose someone wants to fix the year field because the fictional book was published last year (2018), he/she would have to send the COMPLETE updated book info over through a HTTP PUT request.
$ curl --request PUT
--header "Content-Type: application/json"
--data '{"title": "Stackoverflow Compilation Book 1", "year": 2018}'
Notice the change in year attribute.
Considering a HTTP PUT request is essentially a replace operation, one can also replace the book represented by the URI to something else. For instance,
$ curl --request PUT
--header "Content-Type: application/json"
--data '{"title": "Some random book that nobody publishes", "year": 2019}'
The attached data can be in any format (usually also specified in the request header Content-Type, as shown above), as long as it is supported, usually reported by Accept response header (which denotes what kind of data type the application is willing to deal with). Further validation would be handled by the application code to determine whether the submitted data is valid.
You send a HTTP PUT where the body is the 'enclosed entity' that you wish to store under the requested URL. Very similar to POST, it is only the semantics as specified in the RFC, that differ.
If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.