Develop Reference

Sending GET or POST request with Groovy

I want to use HttpURLConnection class in Groovy to send GET and POST (with Jsonbody) request to an api. But what can I tell you. With HttpURLConnection it is soo difficult. I do not know how to use it. There is not even a send method. It looks like when you call getResponseCode() this method sends a request. Then you have to use InputStream and for POST you even have to use OutputStream. Oh my god. For what ?? I am used to handy libraries like Jersey Client. But this HttpURLConnection is just a nightmare. I have to use it because I have jenkinsfile and in my pipeline I need to upload something. And that is possible with calling an REST Api. What do you think about HttpURLConnection ? Does someone know a good website with a GET Request and a POST Request with a body.

I think this is what you are trying to do https://www.baeldung.com/httpurlconnection-post
Making it Groovy should be pretty trivial.
If you are doing an HTTP request and you want to use vanilla Java or Groovy, then I would recommend using HttpClient and HttpRequest.Builder; it's somewhat fluid. And you supply a BodyHandler object, which can be used to get the content however you like it (String, JSON Object, whatever).

REST call in Java

I have a few questions about a specific REST call I'm making in JAVA. I'm quite the novice, so I've cobbled this together from several sources. The call itself looks like this:
String src = AaRestCall.subTrackingNum(trackingNum);
The Rest call class looks like this:
public class AaRestCall {
public static String subTrackingNum (Sting trackingNum) throws IOException {
URL url = new URL("https://.../rest/" + trackingNum);
String query = "{'TRACKINGNUM': trackingNum}";
//make connection
URLConnection urlc = url.openConnection();
//use post mode
urlc.setDoOutput(true);
urlc.setAllowUserInteraction(false);
//send query
PrintStream ps = new PrintStream(urlc.getOutputStream());
ps.print(query);
ps.close();
//get result
BufferedReader br = new BufferedReader(new InputStreamReader(urlc
.getInputStream()));
StringBuilder sb = new StringBuilder();
String line = null;
while ((line=br.readLine())!=null) {
sb.append(line);
}
br.close();
return sb.toString();
}
}
Now, I have a few questions on top of the what is wrong with this in general.
1) If this rest call is returning a JSON object, is that going to get screwed up by going to a String?
2) What's the best way to parse out the JSON that is returning?
3) I'm not really certain how to format the query field. I assume that's supposed to be documented in the REST API?
Thanks in advance.

REST is a pattern applied on top of HTTP. From your questions, it seems to me that you first need to understand how HTTP (and chatty socket protocols in general) works and what the Java API offers for deal with it.
You can use whatever Json library out there to parse the HTTP response body (provided it's a 200 OK, that you need to check for, and also watch out for HTTP redirects!), but it's not how things are usually built.
If the service exposes a real RESTful interface (opposed to a simpler HTTP+JSON) you'll need to use four HTTP verbs, and URLConnection doesn't let you do so. Plus, you'll likely want to add headers for authentication, or maybe cookies (which in fact are just HTTP headers, but are still worth to be considered separately). So my suggestion is building the client-side part of the service with the HttpClient from Apache commons, or maybe some JAX-RS library with client support (for example Apache CXF). In that way you'll have full control of the communication while also getting nicer abstractions to work with, instead of consuming the InputStream provided by your URLConnection and manually serializing/deserializing parameters/responses.
Regarding the bit about how to format the query field, again you first need to grasp the basics of HTTP. Anyway, the definite answer depends on the remote service implementation, but you'll face four options:
The query string in the service URL
A form-encoded body of your HTTP request
A multipart body of your HTTP request (similar to the former, but the different MIME type is enough to give some headache) - this is often used in HTTP+JSON services that also have a website, and the same URL can be used for uploading a form that contains a file input
A service-defined (for example application/json, or application/xml) encoding for your HTTP body (again, it's really the same as the previous two points, but the different MIME encoding means that you'll have to use a different API)

Oh my. There are a couple of areas where you can improve on this code. I'm not even going to point out the errors since I'd like you to replace the HTTP calls with a HTTP client library. I'm also unaware of the spec required by your API so getting you to use the POST or GET methods properly at this level of abstraction will take more work.
1) If this rest call is returning a JSON object, is that going to get
screwed up by going to a String?
No, but marshalling that json into an obect is your job. A library like google gson can help.
2) What's the best way to parse out the JSON that is returning?
I like to use gson like I mentioned above, but you can use another marshal/unmarhal library.
3) I'm not really certain how to format the query field. I assume
that's supposed to be documented in the REST API?
Yes. Take a look at the documentation and come up with java objects that mirror the json structure. You can then parse them with the following code.
gson.fromJson(json, MyStructure.class);
Http client
Please take a look at writing your HTTP client using a library like apache HTTP client which will make your job much easier.
Testing
Since you seem to be new to this, I'd also suggest you take a look at a tool like Postman which can help you test your API calls if you suspect that the code you've written is faulty.

I think that you should use a REST client library instead of writing your own, unless it is for educational purposes - then by all means go nuts!
The REST service will respond to your call with a HTTP response, the payload may and may not be formatted as a JSON string. If it is, I suggest that you use a JSON parsing library to convert that String into a Java representation.
And yes, you will have to resort to the particular REST API:s documentation for details.
P.S. The java URL class is broken, use URI instead.

Best Practice Using JSON to pass data from Java to PHP and PHP to Java Securely

I have been working on an android application project that uses HTTP Get to send and receive data from MySQL through a PHP file using JSON from Java.
I have lately been running into some issues in theory behind best practices using HTTP Transport and passing Parameters via a URL.
First Question:
How should I be passing my data to my PHP Webservices ?
Currently I am just passing the data through single parameters using key value pairs like so:
myurl.com/retrieveinfo.php?user_id=453&password=sha1-hash-value
Should I be moving this type of request to append a JSON object onto the URL instead? like so:
myurl.com/retrieveinfo.php?{\"users\":{\"username\":\"User1Name\" ,\"user_id\":453 , \"password\":\"sha1-hash-value\"}}
Second Question:
*How should I be handling the JSON Response from the Server ? Do I need to push this work off to a handler and make sure the UI Thread is not the one doing this work? *
Currently I am just parsing the JSON using separate methods for each Object Type such as
User.Class
private void parseUserInfo(JSONObject response){
// Do all my Parsing for a User Object
try{
JSONArray users = response.getJSONArray("users");
JSONObject user = users.getJSONObject(0);
// Get the User info etc...
}catch(JSONException ex){
ex.printStackTrace();
}
}
Notes.Class
private void parseNotes(JSONObject response){
// Do all my Parsing for a Note Object
try{
JSONArray notes = response.getJSONArray("notes");
for (int index = 0; index < notes.length() ; index++)
{
JSONObject note = notes.getJSONObject(index);
// Get all the note info etc...
}
}catch(JSONException ex){
ex.printStackTrace();
}
}
Third Question:
I would like my PHP server files to only work for my Application. So what is the best way to secure my PHP files on my server so a request to my files wont go through if its run in a browser ?
Should I be sending some temp key that only my application knows about ?
Thanks

First Question:
You don't really want to put a JSON object on the url as a query parameter. The real two debates that I see is that you either 1) use the key value pairs you were using, or 2) make this a POST and send the JSON as a payload.
Since you are not planning on exposing the API to anyone, I don't really find it important for you to follow standard nomenclatures. Do whatever you want to do. However, from a REST standpoint, anything that retrieves info should be a GET call, and the data should be key-value pairs on the query string. However, it looks like you are passing in a username and password (ok, the sha of the pass). It is considered best practice to always pass user info as the payload. So almost all login type protocols use a POST for user data. User-id's or session id's are common in the query string but usernames and passwords should almost always be in a payload.
Note: sometimes in TLS (SSL) it is considered ok to include these things in the query string.
Second Question:
Honestly, I would just use Jackson. https://github.com/FasterXML/jackson
But otherwise, it is normal to have a seperate layer for parsing. In otherwords, one class handles all the parsing. You do not want to put this code inside your models if you can avoid it. The new layer would handle parsing and would pass the Java Model objects down to the next layer.
Third Question:
The easiest way to do this would simply be to check the user-agent header on the request. Make sure that the user-agent is your application, and not a browser.
However, it would still be possible for people to "spoof" this. Using a temp key wouldn't really help either, because once people sniff the traffic they can figure out the temp key.
The standard thing here is to do some type of session based key, where the application sends some type of MAC in order to prove it is a valid client.
You could also consider using OAUTH2 to protect your api's.

Server side fix for receiving string containing '&'(ampersand)

We have already shipped a client (.NET WinForms) application which sends customer data to Java server. While most of the data sent by client are accepted at server side, some records are truncated because of the presence of & character in it, as client sends raw & and do not URL encode it, we have fixed it by using the below code:
string dataBefore="A & B";
string dataBefore = System.Web.HttpUtility.UrlEncode(dataBefore);
It is impossible for us to update all the client applications(which are already shipped) and we are thinking of a server side fix.
With the help of Fiddler, we have made sure the data has left client in full, but when server reads as below:
//in java
String dataReceied=request.getParameter("data");
it gets truncated if data contains &
Could someone help us suggesting a server side(java) fix for this? Is it possible to access the request stream in java(instead of request.getParameter())?

You can get access to the raw query string using HttpServletRequest.getQueryString() (javadoc), which:
returns a String containing the query string or null if the URL contains no query string. The value is not decoded by the container.
You can them perform manual decoding on that string, instead of using getParameter().
#Wesley's idea of using getParameterMap() may not be useful, because you don't know which order the parameters were supplied in.
I'd suggest implementing this logic as a servlet filter, to decouple the fixing of the broken parameters from your actual servlet logic. This would involve writing a custom subclass of HttpServletRequestWrapper which overrides getParameter() and manuyally decodes the query string. Your servlet would then be able to use the HttpServletrequest API as though everything was tickety boo.

It is cut off because & signifies a new URL parameter in a request like this:
google.com?query=java&page=2. Java converts all these parameters to a Map, so that's where it goes wrong.
Have you tried iterating through request.getParameterMap()? The remaining data is most likely in the name of the next parameter. If that does not work, check out the API of HTTPServletRequest to see if there is another way to get your data.
Good luck!
PS How angry are you guys at the intern that wrote & shipped that client? That sounds messed up!

Is it ok by REST to return content after POST?

I am using RESTlet and I have created a resource. I handle POST by overriding acceptRepresentation method.
The client should send me some data, then I store it to DB, set response to 201 (SUCCESS_CREATED) and I need to return some data to the client, but return type of acceptRepresentation is void.
In my case, I need to return some identificator so that client can access that resource.
For example, if I had a resource with URL /resource and the client sends POST request I add a new row in DB and its address should be /resource/{id}. I need to send {id}.
Am I doing something wrong? Does REST principles allow to return something after POST? If yes, how can I do it, and if no what is the way to handle this situation?

REST just says that you should conform to the uniform interface. In other words, it says you should do what POST is supposed to do as per the HTTP spec. Here is the quote from that spec that is relevant,
If a resource has been created on the
origin server, the response SHOULD
be 201 (Created) and contain an entity
which describes the status of the
request and refers to the new
resource, and a Location header
(see section 14.30).
As you can see from this, you have two places where you can indicate to the client where the newly created resource resides. The Location header should have an URL that points to the new resource and you can return an entity with the details also.
I'm not sure what the difference between overriding acceptRepresentation() and overriding post() but this example shows how to return a response from a POST.

I'd forgo sending anything in the body of the response. Just set Location: to the (full) URL of the newly created resource.
Your description suggests that this is exactly the semantics you:
POST a thing to create it
Respond with enough to know two things:
That the creation happened (the 201)
Where to find the new thing (the Location header)
Anything else is superfluous.

Two different questions:
Does the REST application pattern support returning data in a POST?
I don't think REST explicitly disallows it, but the preferred treatment is spelled out in Darrel's answer.
Does the RESTlet framework allow returning data in a POST?
Yes, even though it returns void, in a class which extends Resource, you have full access to the Response object object via the getResponse() method. So you can call getResponse().setEntity() with whatever data you want.

Output it in whatever format is requested. That might be:
<success>
<id>5483</id>
</success>
Or:
{ "type": "success", "id": 5483 }
It depends on what you usually do. If they're not expecting the data, they should just ignore it, but any client that wants to handle it properly should be able to.

If you respond 201 Created with an entity body, rather than a Location redirect, then it's a good idea to include a Content-Location header pointing to the resource that is being represented in the response.
This will avoid potential confusion - in which a client could (justifiably) assume that the response entity actually represents a new state of the 'creator', and not the created resource.
> POST /collection
> ..new item..
< 201 Created
< Location: /collection/1354
< Content-Location: /collection/1354
< <div class="item">This is the new item that was created</div>