We Keep Coding

How to make $batch POST request using Olingo v2 and Java

I am trying to do a $batch request in Java using OData v2.
An example request from the browser would be something like below between the double quotes.
But how can I make this request programatically? Is there a sample call somewhere? Any help is appreciated.
Request URL: https://someUrl/project/odata/project/FOLDER/$batch
Request Method: POST
Status Code: 202 Accepted
Remote Address: 1.2.3.4:1234
Referrer Policy: no-referrer-when-downgrade
content-encoding: gzip
content-length: 5256
content-type: multipart/mixed; boundary=E828EB257B134AC6F567C8D3B67E666E1
dataserviceversion: 2.0
Accept: multipart/mixed
Accept-Encoding: gzip, deflate, br
Accept-Language: en
Connection: keep-alive
Content-Length: 595
Content-Type: multipart/mixed;boundary=batch_4edb-a2cd-948d
Cookie: project-usercontext=project-language=EN&project-client=100;
--Some cookie content--
DataServiceVersion: 2.0
Host: host.myClient.com:1234
MaxDataServiceVersion: 2.0
Origin: https://host.myClient.com:1234
Referer: https://host.myClient.com:1234/project/index.html
project-cancel-on-close: true
project-contextid-accept: header
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/1.2.3.4 Safari/537.36
x-csrf-token: 8Fd53yy2vuCjnaFKrZNuLg==
--batch_4edb-a2cd-948d
Content-Type: application/http
Content-Transfer-Encoding: binary
GET MyEntityDetailsSet HTTP/1.1
project-contextid-accept: header
Accept: application/json
Accept-Language: en
DataServiceVersion: 2.0
MaxDataServiceVersion: 2.0
project-cancel-on-close: true
> --batch_4edb-a2cd-948d
Content-Type: application/http
Content-Transfer-Encoding: binary
GET MyObjectSet HTTP/1.1
project-contextid-accept: header
Accept: application/json
Accept-Language: en
DataServiceVersion: 2.0
MaxDataServiceVersion: 2.0
project-cancel-on-close: true
--batch_4edb-a2cd-948d--

You can use Olingo V2 as an OData client (although a rather ugly one in my opinion). There is a full tutorial dedicated to this usage on the official Olingo site: How to use Apache Olingo as client library.
Olingo knows to build requests and parse responses, but you need an underlying mechanism to execute the HTTP calls. My recommendation would be to not rely on manually opening HttpURLConnections like in the above example, but to use something like Apache Http Client or some other dedicated library instead (in order to reduce the amount of code you write and also to have access to more advanced concepts like connection polling).
In a nutshell, you must first read and parse the metadata of the service that you want to consume:
// content = read the metadata as an InputStream
Edm dataModel = EntityProvider.readMetadata(content, false);
You can build a batch request via a fluent-style API:
BatchQueryPart part = BatchQueryPart.method("GET")
.uri("/Employees('1')")
.build();
// here you could have a larger list of parts, not just a singleton list
InputStream payload = EntityProvider.writeBatchRequest(
Collections.singletonList(part), "batch_boundary");
Then you have to just execute it using your HTTP request execution mechanism of choice (method = "POST" and body = the payload variable). Afterwards, you can parse the obtained response using Olingo:
// body = the response body received
// contentType = the Content-Type header received
List<BatchSingleResponse> responses =
EntityProvider.parseBatchResponse(responseBody, contentType);
// you can obtain the body for each request from the response list
String partBody = responses.get(0).getBody();
InputStream partStream = new ByteArrayInputStream(partBody.getBytes());
String partType = responses.get(0).getHeader(HttpHeaders.CONTENT_TYPE);
Lastly, using the Edm from the first step you can also parse each individual body based on the type of request that you build. For example you could use the readEntry method to de-serialize a single entity read:
// first we have to find the entity set you used to make the request
EdmEntitySet entitySet = edm.getDefaultEntityContainer()
.getEntitySet("Employees");
ODataEntry entry = EntityProvider.readEntry(partType, entitySet,
partStream, EntityProviderReadProperties.init().build())
Lastly, you can use the entry methods to get e.g. the properties.

Parsing Multipart/mixed in Spring

I want to parse requests like the following in my RestController
POST http://#.#.#.#:#/report HTTP/1.1
User-Agent: Android
Accept: text/html,application/xml,application/json,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Content-Type: multipart/mixed; boundary=%&REPORT_DIVIDER&%
Authorization: Basic ***
Content-Length: 23236
Host: #.#.#.#:#
Connection: Keep-Alive
Accept-Encoding: gzip
--%&REPORT_DIVIDER&%
Content-Type: application/json
{"content-excluded":true}
--%&REPORT_DIVIDER&%
Content-Disposition: attachment; filename="INSTALLATION"
Content-Type: application/octet-stream
609903cf-fcc0-460c-87db-958e031ac156
--%&REPORT_DIVIDER&%--
This message is conform to rfc1341, yet I cannot find a way to parse this in Spring.
Note that the number of files may vary.
I've already tried using CommonsMultipartResolver or StandardServletMultipartResolver, but both only support multipart/form-data (rfc1867).
Is there any way to parse these request in Spring besides writing my own parser?

While it is not a very nice solution, it was the only one I found:
I essentially reimplemented ServletFileUpload with this class and then loaded it into the apache library with this simple subclass of CommonsMultipartResolver

#Path("api")
#PUT
#Consumes("multipart/mixed")
#Produces("multipart/mixed")
public MultiPart twelve( MultiPart multiPart) throws IOException {
List<BodyPart> bodyParts = multiPart.getBodyParts();
BodyPartEntity bpe = (BodyPartEntity) bodyParts.get(1).getEntity();
}
This is for jersey based spring boot project.

Parsing FORM-ENCODED parameters with GRAILS (chargify webhooks)

I have a GRAILS 3 controller that receive an HTTP post from a webservice (Chargify) with this format (the payload section has about 100 entries with a lot of sub-fields):
POST / HTTP/1.1
Accept: */*; q=0.5, application/xml
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
X-Chargify-Webhook-Id: 81309408
X-Chargify-Webhook-Signature: xxxxxxxxxxxxx
X-Chargify-Webhook-Signature-Hmac-Sha-256: yyyyyyyyyyyyyy
Content-Length: 48
User-Agent: Ruby
X-Newrelic-Id: xxxxxx
X-Newrelic-Transaction: aaaaaaaaaaaaaa=
Host: myhost.test.it
id=81197881&event=statement_settled&payload[site][id]=12345&payload[site][subdomain]=test-sandbox
Is there any way with GRAILS to parse the "payload" part and convert it dynamically to a POJO (or also a simple hashmap)?. Chargify use this strange format not recognized by GRAILS framework and I'm unable to parse it automatically.
Is there anyone to help me for parsing? Advance thanks for helping.

Can you try this ?
def readChargify() {
String requestData = request.reader.text
def reqMap = org.grails.web.util.WebUtils.fromQueryString(requestData)
}

This Java library to parse the body of webhooks was contributed by another Chargify customer and may be helpful:
https://github.com/prowave/chargify-webhook-java

parsing form parameters from raw http requests in java

I'm trying to extract some information from raw HTTP Request messages (like the one below) and store them into instances of the org.apache.http.message.BasicHttpRequest (https://hc.apache.org/httpcomponents-core-ga/httpcore/apidocs/index.html) class.
I was able to employ org.apache.http.message.BasicLineParser class and its method parseHeader(String value, LineParser parser) to process (parse + store) the headers, but I don't know how to deal with the parameters passed with the form.
POST https://gist.github.com:443/gists HTTP/1.1
Host: gist.github.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en,fr;q=0.8,it-it;q=0.6,it;q=0.4,en-us;q=0.2
Accept-Encoding: gzip, deflate
DNT: 1
Referer: https://gist.github.com/
Connection: keep-alive
Content-Type: multipart/form-data; boundary=-------------------------10314229756379422411656878663
Content-Length: 1242
-----------------------------10314229756379422411656878663
Content-Disposition: form-data; name="parameter_name"
parameter_value
Do you know an utility which can parse the content starting after the header above (i.e. after the first empty line)? What I am interest in collecting are all the pairs <"parameter_name","parameter_value"> present in the request body.
I have already read similar answers/questions such as Parsing raw HTTP Request but I did not find anything helpful on the form-data component
Thanks in advance for your help and time

What you are seeing is MIME encoded content body. HttpClient is content agnostic and therefore does not provide a means of parsing such content. One can however use Apache Mime4J to do so.

What format and content-type is the body of a paypal rest access token call?

I am using Java with Jersey 2.0 client to make a REST call to the paypal REST API. According to the API doc, I should be making a post to: https://api.sandbox.paypal.com/v1/oauth2/token with the Accept: application/json and Accept-Language: en_US. It also indicates that I should pass in the body grant_type=client_credentials. I do all this but I keep getting a 406 or 415. What I can't figure out is what the Content-Type of the post call should be? I've tried text/plain, text/html, application/json, form-url-encoded.. nothing seems to get me a token back. Not sure why their API doc writer didn't include the Content-Type and format of the payload in the documentation. Anyone know what the Content-Type should be for the body of the post?
I'd like to add that when I do any Content-Type other than form-url-encoded, I get back 415, which means mediatype not accepted, however when I pass in anything using form-url-encoded, I get back the 406, which basically tells me the body is not acceptable.
Thanks.

Thanks for bringing up the question.
There was a recent change in the /token call and requests for an access token need to have the content-type set as application/x-www-form-urlencoded. This is done by default in cURL calls.
Updated docs that include a note about this will be going out very soon.

Inbound the OAuth 2 endpoint only accepts "application/x-www-form-urlencoded" or it will throw a 415, the payload then needs to be properly url encoded. Likewise the accepts header needs to contain "application/json", or the service will throw a 406.
For example:
Headers:
Authorization: Basic [base64 encoded]
Content-Type: application/x-www-form-urlencoded
Accepts: application/json
Payload sample:
grant_type=client_credentials&response_type=token