The Docusign Java SDK doesn't have built-in support for creating envelopes with multiple documents as binary. This is cumbersome for users. People asking about have been directed to this one-off example code using Java's native HttpsUrlConnection: Docusign Multipart Request To Create Envelope using java SDK (the current link for this source is here: https://raw.githubusercontent.com/docusign/code-examples-java/ee8489ca749a007767f07e1871ec9be100b5abb2/src/main/java/com/docusign/controller/eSignature/services/SendBinaryDocsService.java) or raw HTTP request as at Docusign - send envelope REST API (POST multipart/form-data ). The sample code uses the raw HttpsURLConnection class to make HTTP requests, different from how ApiClient uses Jersey to make requests.
Why is this common use case not just built into the SDK? The SDK does actually have some multipart support in ApiClient.java https://github.com/docusign/docusign-esign-java-client/blob/master/src/main/java/com/docusign/esign/client/ApiClient.java serialize() and invokeAPI() methods, using Jersey parts. Note that FormDataContentDisposition is used, which will result in individual parts having the name "form-data". Also this route is not available for the EnvelopesApi.createEnvelope() method.
It's tempting to just make a direct ApiClient.invokeAPI() call to try and make use of this, but the code starting "// Generate and add Content-Disposition header as per RFC 6266" seems like it overwrites the "entity" with each individual part, so this may not work with more than one part?
The documentation of the API is found here: https://developers.docusign.com/docs/esign-rest-api/how-to/send-binary/ Both the description and sample code use "Content-Disposition: file..." while the web spec states that for each individual part of a multipart body "The first directive is always form-data" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) - which ApiClient itself does for its own multipart support.
ETA: experimentation shows that using "Content-Disposition: form-data" actually works fine
Clients are also asked to include "documentid=N" in the Content-Disposition, but it appears difficult to add this extra parameter at least when using Jersey's FormDataContentDisposition. If you look inside the source of glassfish FormDataContentDisposition / ContentDisposition you can see that only a fixed list of parameters will be included in the string buffer.
It would greatly help SDK users if we could get:
official support for creating envelopes with multiple binary documents in the official SDKs
alternatives to proprietary customizations of Content-Disposition header
this would make life much easier for Java SDK consumers. Apologies if I got anything wrong here.
A well written question. To better register your sdk enhancement request, see feedback.docusign.com and request via your DocuSign sales person.
THE SDKs are autogenerated from our swagger file. So your request would be a large project and is not currently planned.
While uploading with base64 encoding is inefficient, it works fine.
Related
I was wondering if it was actually possible to create a Java SOAP Webservice without using it's WSDL.
Context:
The idea is that I have to mock a webservice, so I have its WSDL. The mock will only read the soap request, search if there are any similar request (as key in a map) and send the matching response (as its value). This is for automated testing purpose. The problem is not the "map" part.
Anyway, I've been using Axis and eclipse to generate classes and files and load them in tomcat from the WSDL. So far it've been a mess, with a lot of compatibility issues between these components. And it's gonna be much more difficult to compare the input or serialize the output to do what I want this way.
I thought about creating a REST endpoint and send the soap request through it (so I would directly get the SOAP request !), but I rode somewhere that soap request weren't valid and wouldn't be retreived by the REST endpoint... Also, won't the client application throw an error if there is no WSDL at this address ?
My question is:
Is there a way to create an access point, that looks like a SOAP Webservice (from clients), but which allows me to get the full soap request (as a String for example) and send a response (still as a String) inside a Java app?
Complements:
I'm looking for something, a library, maybe just an annotation on Servlets, that doesn't needs (if possible) to generate a huge load of classes and xml files everywhere. The app would be running on tomcat (but I can be a basic Java app). Using maven and spring wouldn't be a problem.
Thanks in advance !
Normally, clients do not require an WSDL. But it is a nice feature - use a normal servlet and handle the "?WSDL" manually. Then use some simple XPath or parse logic to extract the payload as a DOM document.
I'm new to this and I need my Java program to send http or https requests on the different websites(for example, Amazon)
so it can get the HTML code and than I would be able to find information(price on some goods) that I need via Pattern class.
Did anybody faced with that task? Maybe you used JSON or other tools? Thank you.
It seems that Amazon have an API. You should using instead of trying to parse their website.
Regarding libs to call webservices in JAVA, you could use Retrofit.
There are several parts to what you are asking:
Constructing / determining what to include in the HTTP request
Issuing the actual HTTP request
Parsing the response
The first and last are dependent on the particular service / API you are invoking, though if the API response is in a standard format (e.g. JSON), there are libraries that can help you interpret the response (though exactly which fields in the response mean something to you, will depend on the particular API and your application). Issuing the HTTP request, itself, is something that can be done with a number of different libraries, including the builtin HttpURLConnection / URL classes, as well as third party libraries such as the Apache HttpComponents or the Google HTTP Java Client Library, the latter of which includes libraries for parsing common output formats, as well.
I am using web services of third party for my web application.
For updating an entity they providing MERGE method (POST method they are using for new entity(it requires all the fields)) so i have searched for this method is there any sample provide but no success.
Can somebody tell me how can i achieve this.
Can somebody also tell me how to use PATCH method as well??
thanks in advance.
The MERGE and PATCH methods are not supported by HttpURLConnection.setRequestMethod.
Here is the documentation for HttpURLConnection.setRequestMethod:
Set the method for the URL request, one of: GET POST HEAD OPTIONS PUT DELETE TRACE are legal, subject to protocol restrictions. The default method is GET.
Is your third party web service an OData service? The MERGE method was invented for OData and doesn't exist in the official HTTP protocol. Here is the relevant documentation from Microsoft (the inventor of OData):
The remainder of this section defines a custom HTTP MERGE method that is used in the OData 1.0 and OData 2.0 protocols to specify that an update is to be completed by using merge semantics... The only difference between an HTTP request that uses MERGE or PATCH and PUT is client intent... Since MERGE is not one of the verbs that is defined in the HTTP specification [RFC2616], using the MERGE verb might not flow through network intermediaries as seamlessly as methods that are defined in the HTTP specification...
As a solution, I would suggest sending your payload in an OData batch request. This is a special POST request whose payload can include multiple HTTP requests. You can specify your MERGE and PATCH requests inside the batch payload.
I am writing a REST web service for clients to download large data files. As part of this, I would like to implement a feature to enable resuming interrupt downloads in case an exception occurs or the connection is lost on the original request.
I did some research online and found that supporting Range/If-Range properties in the request header might be the solution, as indicated in http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html.
My question are
In the scope of REST web service, is it the most commonly used and best practice to support Range/If-Range properties in the client HTTP request header, or just pass the byte offset as a query parameter in the client GET request, e.g., hostname:port/download?token=?byteoffset=??
If taking the former approach, on the server side, is there a standard way to handle request with Range field in JAX-RS specification (I am using Java)? The straightforward way is to just open an InputStream from the file and bypass the given # of bytes.
In general, don't use parameters that have to do with meta-information on the resource (or the part of it you need), so you should be using the Range, and keep sure the server allows that.
Note that, for example, byteoffset is not a meaningful part, component or semantically interesting bit of the resource itself, but a way of overcoming partial content (also, identical for all the resources, so you have to use the headers allowed for that, and hey! they're there for that).
I'm looking for a way to get the form parameters of a HTTP multi-part request in a Servlet-filter without uploading files (yet).
request.getParameterMap() returns empty. I understand this is because of the request being multi-part.
I've looked at commons.HttpFileUpload but this seems to be overkill for my situation. In this filter I'm only interested in the normal parameters, and don't want to handle the file-upload yet.
Edit: the main problem is that I need to have an intact HttpRequestObject further down the filter stack. The HttpFileUpload seems to consume part of the request data (probably by using the data stream object and closing it again.)
It's certainly not overkill, it's the right way and always better than writing the parser yourself. The Apache Commons FileUpload is developed and maintained for years and has proven its robustness in handling multipart/form-data requests. You don't want to reinvent the wheel. If you really want to do it (I don't recommend it), then read on the multipart/form-data specification and start with reading the HttpServletRequest#getInputStream() (warning: this is a mix of binary and character data!).
You can if necessary also write a Filter which makes use of Apache Commons FileUpload under the hood and checks every request if it is multipart/form-data and if so, then put the parameters back in the request parameter map with help of Commons FileUpload and put the uploaded files (or exceptions) as request attributes, so that it's finally a bit more transparently in your servlet code. You can find here a basic example to get the idea.
Hope this helps.
Just to add to the answers already provided - I had a very similar problem in that I was trying to add some CSRF validation to our existing web app. We decided to include a special token in each form using some JS and add a servlet filter to check that the token existed (therefore a generic, isolated solution).
The servlet would check if the token was present but broke for every form that provided a file upload option. Hence I landed at this page frequently while doing some googling.
The work around we used (while attempting to avoid any dealings with the uploaded files) was to get some JavaScript to add the token as a GET parameter, i.e. We modified the form's action URL to include the token and therefore could use the HttpServletRequest.getParameter() method for the token (and only the token).
I have tested this in IE, FF and Chrome and all seem to be happy.
Hope this helps anyone who also finds themselves in a similar situation.
The Oreilly Servlets website has some sample code which you can download customise and use. This includes MultipartRequest which sounds like it does what you require, it un-boxes a multipart request and allows access to the parameters and the files separately.
Commons FileUpload provides a mechanism to read request params from a multipart form upload.
There's a really great example of how to grab the request parameters here:
How to upload files to server using JSP/Servlet?