I have a DESKTOP application which interacts with a web service through their RESTful api and OAuth 1.0. I can use all the resources fine, authentication, get/post calls to retrieve and send simple text data etc, no problems there.
However, I'm struggling to send binary data. The service allows sending pictures. For one part, they have a non-OAuth api through which you can also send a file in plain binary, simply pass some params in the URL and put the entire binary file in the post.
Now to do this through the OAuth api, becomes an issue:
The service specifies the post needs 2 parameters (not to be included in the URL since this is REST, but in the POST parameters):
image A binary file, base64 data, or a URL
type The type of file that's being sent in. Accepted values: file, base64, url
So we have 2 parameters: image contains the file itself, and type would be "file" to specify binary. But how am I supposed to include this through OAuth? given that the -image- and -type- parameters (and their values) must be used to generate the base string for the signature, which is matched against the parameters included in the POST.. I can't include the entire binary there as a value for the image parameter; so how is it done in this case?
nvm, their OAuth api expects the file as multipart/form-data with the variables there, and none in the base string for the signature (their non-OAuth api instead doesn't need multipart, so I expected their OAuth wouldn't either; their documentation is a bit lacking in this area).
Related
I'm trying to use a logicapp to get the content of an email and post it to slack. By content I mean:
the body of the email and other elements like From:, Subject:
any attachment in the email (which usually are binary like PDF, Excel, image)
the email itself saved in a blob as .eml file
Slack chat.postMessage API works without any problem to send any text element. This API has some attachment argument but doesn't seemto be designed or binary files (or not for files at all, only strings)
I've tried slack files.upload one but couldn't figure out the syntax, especially the syntax using a regular HTTP POST. Could find examples online using curl, Python, JS and C# SDK but I don't know how to translate them to HTTP POST just like I do with chat.PostMessage
I've tried the API on SOAP UI, using file as argument as per the documentation, and I've used it in different sections: in the header, in the body, and using the Attachment Tab, none of the work and always the same error message : no_file_data
Unfortuatelly slack documentation lacks of details. Here's what it says about files.upload:
You must provide either a file or content parameter.
The content of the file can either be posted using an enctype of multipart/form-data (with the file parameter named file), in the usual way that files are uploaded via the browser, or the content of the file can be sent as a POST var called content. The latter should be used for creating a "file" from a long message/paste and forces "editable" mode.
In both cases, the type of data in the file will be intuited from the
filename and the magic bytes in the file, for supported formats.
I could use alternatives like just saving the attachments in blobs and use Azure functions to send the file, but I want to understand what's the limitations before changing the method.
Any clue?
I'm attempting to create a REST API method that accepts multiple file uploads with some additional arguments. This API method will be called from both web forms, web services or mobile apps.
Is there a standard I should be following with regards to how the method takes these parameters in?
So far, I've considered the following two approaches:
JSON body: file data to be included as base64 encoded fields within the JSON object. Fine if being called from other web services, but troublesome when calling from a HTML form?
multipart/form-data: easy to use with HTML forms, but problematic when calling from web services or mobile apps?
I know that either of the two approaches would work, but I'd like to implement this the correct way (if there is one) according to current standards. Any ideas?
Do modern JS libraries/frameworks make it easy to POST HTML forms to web APIs as JSON objects
Yes, we have a lot of library to convert the file into base64.
In my opinion, choose what is based on your requirement. Firstly, exchanging data in multipart format should be more efficient than base64 json string. But this article show, the term of the size is little.
But if we use json, you could pass multiple other variable in the json format and we could read it easily.
Besides, if your file is image, the browser understand data URIs (base64 encoded images), there is no need to transform these if the client is a browser.
I've been using Postman's API mock features, but they are not smart enough to detect when a field is missing from the body and send a different response depending on the validity of a request (it can only do it with url parameters in GET requests).
Is there any solution that is able to parse a swagger/openapi file and create those programmatic differences?
I'm designing a list endpoint for a resource that merits both full and light version of the resource called /transactions. By default, the response will include the complete resource, but there is also a need to provide clients with the "simplified" version of the resource list.
The first option is to use a custom param (e.g. /transactions?summary=true)
The second option is to use a custom endpoint, though not very RESTful (e.g. /transactions/summary)
The third option is to use content-type to allow a client to declare the alternative response body format. How would this look? (application/json+summary)? Are there any good examples of this being done?
Any other options come to mind?
The third option of using the Accept/Content-Type headers allows the media types to be a representation of a data, separate from the data itself.
A good example of this is github's API: https://developer.github.com/v3/media/
Which uses the http headers to allow clients to choose the format of the data, as well as the version. So in your case, the request could look something like:
curl http://api.host.com/transactions -H "Accept: application/summary+json"
And the response would contain a body of your simplified data format and the Content-Type header set to application/summary+json
If you want to be more pedantic about it, you could also use a vendor media type as application/vnd.yourcompany.summary+json. In this case, vnd implies that the media type is a vendor typically associated with application specific media types.
More Info:
Collection+JSON
A similar answer
A bit from restful API design
We're using Python and the Requests library to add PDFs to DocuSign envelopes using the Add document method of the REST API v2:
response = requests.put(
'<base URL>/envelopes/<envelope ID>/documents/<next document ID>',
files={'document': <the PDF file object>}, # <- added to the request's body
headers=self._get_headers(
{
'Content-Disposition': 'document; filename="the-file.pdf";'
}
),
timeout=60
)
This has worked for us in most cases, except that about 1 in 100 PDFs isn't accepted via the API. When this problem occurs we tell our users to upload the PDFs directly through the DocuSign UI, which works. This prompted us (with the help of support) to look at the Document params link that appears above the example request on the Add document page linked above. The page shows a documentBase64 attribute, and a number of other fields. How can I supply the document in this format, with all the fields specified? Should I replace the file in my call above with files={'document': <JSON-encoded object>} or? I can't figure out how to add a document OTHER than the way we're currently doing it. Is there another way I'm missing?
It looks like there are now two different ways to add a document to a Draft Envelope with the REST API:
Use a multi-part request, where the first part contains the JSON body and each subsequent part contains a document's bytes -- in un-encoded format. An example of this approach is shown on pages 136-137 of the REST API guide (http://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf).
Use a normal request (i.e., not multi-part request), and supply document bytes in base64-encoded format as the value of the documentBase64 property for each document object in the Request. (This looks to be new as of the recent December 2013 API release/update.)
Based on the info you've included in your question, I suspect you're currently using approach #1. As described above, the main difference between the two approaches is the general structure of the request, and ALSO -- approach #1 expects document bytes to be un-encoded, while approach #2 expects document bytes to be base64-encoded. I suspect your issue has to do with encoding of files. i.e., if you're using approach #1 and any of the files are encoded, you'll likely have issues.