Develop Reference

I can't use the invokeHTTP with Post method on NIFI

I have no problem making NIFI post type requests. In the articles I've seen, I used the "invokeHTTP" component, with a "post" configuration inside it. I need to send a JSON to a fixed address, and invokeHTTP does not work. You can do the same thing with POSTMAN and it works, however in NIFI I can not.
I placed the request body in the "Put Response Body In Attribute" field.
The design can be done with CORS do not disturb (The project and the NIFI are in local network, in port 8081 and 8088 respectively).
I would like to know if anyone has any hints as to why my project does not receive a NIFI request, but receives from POSTMAN. Can I, be setting something wrong ...

I think the issue is the request body. It sounds like you are putting the request body in the attribute specified in the Put Response Body In Attribute property.
For InvokeHTTP the flowfile contents are included as the body of the request.
Place the JSON you want to send via an HTTP POST in the content of the flowfile prior to the flowfile reaching your InvokeHTTP processor.
The Put Response Body In Attribute property specifies that the HTTP response body should be written to a named flowfile attribute as part of the input flowfile (rather than the default behavior, which is to generate a new output flowfile with the content of the HTTP response).

How to keep ResponseBody on 204 No Content response?

I want to return a 204 no content http status code. Though I want to add a custom error messages that gives details why where was no content.
Problem: I'm using spring-mvc, and when returning HttpStatus.NO_CONTENT type, the response body is always removed and empty for the client!
#RestControllerAdvice
public class ExeptionHandler {
#ExceptionHandler(Exception.class)
#ResponseStatus(HttpStatus.NO_CONTENT)
public Object handler(HttpServletRequest req, Exception e) {
return new ResponseEntity<String>(e.getMessage(), HttpStatus.NO_CONTENT);
}
}
If I change the type eg to HttpStatus.NOT_FOUND then the error message is shown as response body.
How can I achieve the same with 204?

I want to return a 204 no content HTTP status code. Though I want to add a custom error messages that gives details why where was no content.
You can't.
Problem: I'm using Spring MVC, and when returning HttpStatus.NO_CONTENT type, the response body is always removed and empty for the client!
That's the expected behaviour.
If I change the type eg to HttpStatus.NOT_FOUND then the error message is shown as response body. How can I achieve the same with 204?
You won't achieve it with 204. You are misunderstanding (and probably misusing) such status code. The purpose of 204 is to indicate that the server has successfully fulfilled the request and there's not additional content to send in the response payload.
For reference, see how this status code is defined in the RFC 7231:
6.3.5. 204 No Content
The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional
content to send in the response payload body. [...]
A 204 response is terminated by the first empty line after the header
fields because it cannot contain a message body. [...]
Depending on the situation, you'd better use 404 or 200 with an empty array in the response payload. This answer may give you some insights.

204 is for successful requests. It should have no error message included.
If an error happened, a different HTTP Code should be used.
see https://httpstatuses.com/204
A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.

What is the HTTP status return code for a successful DELETE statement in REST?

I am studying how to Spring handle REST web services (but I don't know if it is a Spring related answer or more generically it is related only to REST concept).
So my doubt is: what exactly is the HTTP status return code for a successful DELETE statement?
Is it the 204 or the 200?
I know that the 200 means that my request was correctly fulfilled but reading online it seems to me that it I expect it after a successful GET returning content and not after a delete.
Somewhere I found that the 204 status is obtained after
successful PUT or DELETE. Is it true? I can't understand, it means that the response is empty, why an empty respons means that the PUT or the DELETE operation are gone succesfull?

There are no strict rules on which HTTP status code is the correct one for each method. It depends on what exactly happened, what information you need to send to the client, etc. I can think of a few examples:
A successful DELETE, with no further information. 204 No Content
A successful DELETE, but you have a warning about related orphan resources that should be deleted too. 200 OK.
You accepted the DELETE request, but it might take a long time and you're going to do it asynchronously. The client should check it later. 202 Accepted.
You accepted the DELETE request, but the resource can't be removed and the URI is instead reset to a default. 205 Reset Content.

An empty response body doesn't mean that a delete is successful, a successful delete (usually) means that the response body is empty.
There's no official status code list for RESTful APIs, but most agree that a 204 is a good response code for a successful delete, as there's usually not a good reason to return a response body after deleting something.
In general, if an operation is successful and the response body is empty return 204. If an operation is successul and the response body is NOT empty, return 200

An empty response doesn't mean the operation was successful, the HTTP error code is supposed to indicate success/failure, and the response body may or may not contain data.
The response body may contain additional information regarding the request, e.g., a specific message to display to the UI, stats or timing info regarding the information, whatever. But it doesn't have to, and the body's purpose is informational/diagnostic if it exists.

2xx represents the request was successful. The xx just allows for you to be more specific about what happened (what the server did or is returning).

Getting "411 Length Required" after a PUT request from HTTP Client

I am working on a Java program that implements an HTTP Client.
I test it sending requests to a server. GET, POST and DELETE requests work ok.
For example after a POST request I get an output
Data extracted:
{"status":{"message":"ok"}}
and the database reflects the changes made.
After a PUT request, however I get the following html markup of a webpage indicating an error.
Data extracted:
<html>
<head><title>411 Length Required</title></head>
<body bgcolor="white">
<center><h1>411 Length Required</h1></center>
<hr><center>nginx/1.2.6</center>
</body>
</html>
and accordingly no changes in the database.
I found that this can have something to do with the Content-Length header, but I'm not sure.
After trying to add this header my program waits for a minute and then throws an exception informing that it couldn't handle the server response.
I can also provide any code or stack trace if needed.

Yes, the issue related to Content-Length. HTTP Error 411 means
The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.
So when you send an empty RequestBody in POST/PUT Method then you also need to send Content-Length:0. So add this header in your request. I don't think this header will cause a problem of you added into Request Object.

Does the server send response only when its HTTP 200?

im writing a java application that sends a post request to a server and expect a json from the server. Now when i need to get the response from the server do i only need to get it from the inputStream when the http code is 200 (HTTP OK) or is there any other cases ? , example :
//...
if (urlConn.getResponseCode() == HttpURLConnection.HTTP_OK) {
// only here try to get the response
}
//...

It depends on how the server is implemented. Check the API, if the server has one. If it's internal, ask your server guy.
Generally speaking, if your response code is either 2xx or 3xx, I would check the response anyway...

If the server your communicating with is following the spec then either 200 or 201 responses are valid to contain an entity. A 204 response is successful but has no data in the response.
See section 9.5 here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.5 for details of acceptable responses to a POST. Extract below:
The action performed by the POST method might not result in a resource
that can be identified by a URI. In this case, either 200 (OK) or 204
(No Content) is the appropriate response status, depending on whether
or not the response includes an entity that describes the result.
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).

There are three things to consider:
All 2xx codes denote success of some sort. But depending on the exact code, your reading code might be different. (204 for example means success but no content.)
There are redirecting codes (3xx). These are usually automatically followed by the http client library but you can also set them not to, in which case you need to have custom code that handles these cases.
There can be valuable information returned in the stream even if you get a code that denotes an error. Whether you want to process it depends on your exact needs.