I have been trying to create a REST/Json Virtual service on CA LISA 7.5 (we can’t update), using request response pairs. The request response looks like the following:
Name-req
GET /cods_party_web/party/111700 HTTP/1.1
Pragma: no-cache
Cache-Control: no-cache
x-abc-outlet-id: 017879
x-abc-user-id: CTM
x-abc-consent-level: 2
x-abc-application-id: 00028
x-abc-outlet-id-type: OU_ID
x-abc-user-id-type: 1
x-IBM-Client-Id: XXX....
x-IBM-Client-Secret: XXX...
Name-rsp
HTTP/1.1 200 {"party":{"partyId":111700,"foreNames":["Julie","Pamela",""],"lastName":"Duncan","initials":["J"],"...lots of content......."type":"EMAIL"}],"associatedOU":null}
When I try to build the virtual service image, no matter what options I select, my VS image response is either in hex as shown below or it is blank.
I remember having this problem 1 year ago, and was able to get the reponse to look like below but I can’t remember how I did it.
Success response
Not found response.
Many thanks in advance
It's not returning hex - those are just column numbers for an empty binary response. I think the problem is your response document is not properly formed HTTP - there's no reason phrase in the status line, and you need two line feeds after the status line. Try this:
HTTP/1.1 200 OK
{"party":{"partyId":111700,"foreNames":["Julie","Pamela",""],"lastName":"Duncan","initials":["J"],"...lots of content......."type":"EMAIL"}],"associatedOU":null}
I understand that you can't upgrade, so this doesn't really help you, but LISA 9.5 doesn't have this issue -- the response looks like it's supposed to.
On the other hand, CA has released a free, simpler version of LISA that also successfully generates a VS from your example. Check it out here:
http://educationcontent.ca.com/A01/index.html
Related
I didn't find useful information about which methods status is correct for absent object in db.
For example I have deleted user with id = 1, but someone try to get it's information thought GET method with query params id=1.
Which status will be right: 404, 204, 400,406 or 410?
I didn't find useful information about which methods status is correct for absent object in db.
Yup, that's right - HTTP status codes don't tell you anything about rows in a database, what they tell you about are documents ( "resources" ) in a document store.
More precisely, the HTTP status code is metadata that tells general purpose components (like a web browser, or a cache) what's in the message-body of the response.
Depending on what document you put into the message-body, the appropriate status code could be any of:
200
404
410
200 announce that the message-body is a document (more broadly, a current representation of the resource). 404 and 410 (and all 4xx and 5xx status codes) announce that the message-body is a representation of the explanation of the error.
404 indicates that the document identified by the effective target uri of the request doesn't exist right now, but it might exist later; you can attach caching metadata to communicate when the might check again.
410 indicates that the document identified by the effective target uri of the request doesn't exist right now, and that condition is likely permanent. That permanence implies that clients can delete bookmarks, and remote links to the document should be removed, and so on.
If you recycle ids, or if deletes ids can be restored, then 410 isn't an appropriate choice.
In some APIs, resources have current representations even when there is no matching information in the database.
In other words, the current representation of the resource might be an empty document
200 OK HTTP/2
Content-Type: text/plain
Content-Length: 0
or it could be a null object
200 OK HTTP/2
Content-Type: application/json
Content-Length: 4
null
or it could be an empty list
200 OK HTTP/2
Content-Type: application/json
Content-Length: 2
[]
or an empty object
200 OK HTTP/2
Content-Type: application/json
Content-Length: 2
{}
or a meme
200 OK HTTP/2
Content-Type: text/plain
Content-Length: 36
This space intentionally left blank.
The status code to use follows from the decision to use a sort of "default" representation of our document when there is no specific information available.
The more common decision, of course, is to choose not to provide default representations, but instead announce that the client has made a mistake (in which case the 4xx class of status code is the correct starting point).
Isn't it write to return 204(NO CONTENT) status or something similar? 'Cause I think 200 is not fully informative status
Maybe - there's some ambiguity in the HTTP standard, and because of that ambiguity I tend to be biased against 204 (today; if you look up some of my older answers, I was much likely to try 204 in the past).
RFC 7231, Section 6.3.1
Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 (No Content) instead.
So we have two different ways to send zero bytes of data back to the client; either 200 with Content-Length set to zero, or 204.
Are those two things the same?
The answer seems to be "not quite"; there's a subtle difference documented in section 6.3.5
The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any).
Now, think about that in the context of a web browser. If I click a link that points to an empty file, a 200 response would mean that the browser would traverse away from the current "document view" to show me the empty file. But the language of 204 suggests that instead the browser should stay put, and just indicate that the empty file was successfully downloaded.
Note: I haven't done any experiments to see if browsers do act that way; my only claim is that staying in place is the specified behavior.
My reading of the specification is that 204 is designed to support a use case that only arises in the context of unsafe actions, like PUT. You can see hints of that as far back as HTTP/1.0
This response is primarily intended to allow input for scripts or other actions to take place without causing a change to the user agent's active document view. The response may include new metainformation in the form of entity headers, which should apply to the document currently in the user agent's active view.
In short, responding with a 204 to a GET request is placing a bet that the authors of general purpose components have interpreted an ambiguous part of the specification the same way that you do -- and I don't like that bet at all. Much more reliable to use the well understood 200 response, and avoid the unnecessary ambiguity.
We use talend to build ETLs. One of the components we use is tRESTClient, to interact to a REST service in our platform. We use talend version 7.1.
Recently this REST service has changed the version of its HTTP server library (libmicrohttpd, the REST service is based in C/C++). In particular, has moved from limicrohttpd 0.9.48 to 0.9.70. And since we did the change, the integration in the ETL has started to fail. We see message likes this in the talend traces:
--------------------------------------
time=2020-08-05 08:26:01| lvl=INFO | ver=1.0| Inbound Message
----------------------------
ID: 1
Response-Code: 204
Encoding: ISO-8859-1
Content-Type:
Headers: {Cache-Control=[no-cache, no-store, max-age=0, must-revalidate], connection=[keep-alive], Date=[Wed, 05 Aug 2020 06:26:03 GMT], Expires=[0], fiware-correlator=[894f7ff0-d6e4-11ea-b1bd-fa163ec74401], Pragma=[no-cache], Referrer-Policy=[same-origin], Server=[nginx], Strict-Transport-Security=[max-age=31536000; includeSubdomains;], X-Content-Type-Options=[nosniff], X-Frame-Options=[SAMEORIGIN], X-XSS-Protection=[1; mode=block]}
--------------------------------------
Exception in component tRESTClient_1 (VLCI_ETL_MEDIOAMBIENTE_INSERT_CB)
javax.ws.rs.client.ResponseProcessingException: Problem with reading the data, class org.dom4j.Document, ContentType: */*.
at org.apache.cxf.jaxrs.impl.ResponseImpl.reportMessageHandlerProblem(ResponseImpl.java:437)
at org.apache.cxf.jaxrs.impl.ResponseImpl.doReadEntity(ResponseImpl.java:379)
at org.apache.cxf.jaxrs.impl.ResponseImpl.readEntity(ResponseImpl.java:314)
at org.apache.cxf.jaxrs.impl.ResponseImpl.readEntity(ResponseImpl.java:304)
…
We are still investigating the problem but we suspect that one of the changes introduced in libmicrohttpd could be related. In particular, with libmicrohttd 0.9.48 (when the ETL works) “Content-Length: 0” header was included in 204 responses. With libmicrohttpd 0.9.70 (when ETL doesn’t work) such “Content-Length: 0” header is not included.
Is this a known issue? I mean, is tRESTClient (version 7.1) expected to fail if “Content-Lengh: 0” is not included in 204 responses?
Note that the HTTP specification is pretty clear regarding Content-Length usage in 204 responses. From RFC 7321 (which as far as I know is the normative standard on HTTP) section 6.1:
A server MUST NOT send a Content-Length header field in any response with a status code of 1xx (Informational) or 204 (No Content)”
so if tRESTClient is not supporting it, then I understand is a bug in talend (maybe solved in post-7.1 releases?)
Any feedback on this is really welcomed! Thank you for your attention.
Finally, it seems we have solved the issue in the following way.
In the failing situation the component was using this configuration:
We have changed Accept Type from "JSON" to "Any" in the following way:
And now it is working.
My guess is that with Accept Type "JSON" the component is waiting for a response payload and this is problematic in the case of 204 No Content. Using "Any" removes that restriction.
Maybe it worked by chance with the non-standard content-length: 0 header in this case... It's a bit weird anyway, I think the tRESTClient should deal with this situation better than this. Maybe is a behavior already fixed in the post-7.1 versions.
Any feedback or comment on this solution would be welcomed. Thanks!
I'm trying to issue a GET command to my local server using netcat by doing the following:
echo -e "GET / HTTP/1.1\nHost: localhost" | nc localhost 80
Unfortunately, I get a HTTP/1.1 400 Bad Request response for this. What, at the very minimum, is required for a HTTP request?
if the request is: "GET / HTTP/1.0\r\n\r\n" then the response contains header as well as body, and the connection closes after the response.
if the request is:"GET / HTTP/1.1\r\nHost: host:port\r\nConnection: close\r\n\r\n"
then the response contains header as well as body, and the connection closes after the response.
if the request is:"GET / HTTP/1.1\r\nHost: host:port\r\n\r\n" then the response contains header as well as body, and the connection will not close even after the response.
if your request is: "GET /\r\n\r\n" then the response contains no header and only body, and the connection closes after the response.
if your request is: "HEAD / HTTP/1.0\r\n\r\n" then the response contains only header and no body, and the connection closes after the response.
if the request is: "HEAD / HTTP/1.1\r\nHost: host:port\r\nConnection: close\r\n\r\n" then the response contains only header and no body, and the connection closes after the response.
if the request is: "HEAD / HTTP/1.1\r\nHost: host:port\r\n\r\n" then the response contains only header and no body, and the connection will not close after the response.
It must use CRLF line endings, and it must end in \r\n\r\n, i.e. a blank line. This is what I use:
printf 'GET / HTTP/1.1\r\nHost: www.example.com\r\nConnection: close\r\n\r\n' |
nc www.example.com 80
Additionally, I prefer printf over echo, and I add an extra header to have the server close the connection, but those aren’t needed.
See Wiki: HTTP Client Request (Example).
Note the following:
A client request (consisting in this case of the request line and only one header) is followed by a blank line, so that the request ends with a double newline, each in the form of a carriage return followed by a line feed. The "Host" header distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
The absolute minimum (if removing the Host is allowed ;-) is then GET / HTTP/1.0\r\n\r\n.
Happy coding
I was able to get a response from my Apache server with only the requested document, no response header, with just
GET /\r\n
If you want response headers, including the status code, you need one of the other answers here though.
The fact of the 400 Bad Request error itself does not imply that your request violates HTTP. The server very well could be giving this response for another reason.
As far as I know the absolute minimum valid HTTP request is:
GET / HTTP/1.0\r\n\r\n
Please, please, please, do not implement your own HTTP client without first reading the relevant specs. Please read and make sure that you've fully understood at least RFC 2616. (And if you're ambitious, RFC 7230 through 7235).
While HTTP looks like an easy protocol, there are actually a number of subtle points about it. Anyone who has written an HTTP server will tell you about the workarounds he had to implement in order to deal with incorrect but widely deployed clients. Unless you're into reading specifications, please use a well-established client library; Curl is a good choice, but I'm sure there are others.
If you're going to implement your own:
do not use HTTP/0.9;
HTTP/1.0 requires the query line and the empty line;
in HTTP/1.1, the Host: header is compulsory in addition to the above.
Omitting the Host: header in HTTP/1.1 is the most common cause of 400 errors.
You should add an empty line: \r\n\r\n
http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Client_request
The really REALLY BARE minimum, is not using netcat, but using bash itself:
user#localhost:~$ exec 3<>/dev/tcp/127.0.0.1/80
user#localhost:~$ echo -e "GET / HTTP/1.1\n" >&3
user#localhost:~$ cat <&3
HTTP/1.0 200 OK
Server: SimpleHTTP/0.6 Python/2.7.6
Date: Mon, 13 Oct 2014 17:55:55 GMT
Content-type: text/html; charset=UTF-8
Content-Length: 514
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html>
<title>Directory listing for /</title>
<body>
<h2>Directory listing for /</h2>
<hr>
<ul>
</ul>
<hr>
</body>
</html>
user#localhost:~$
I need to create a method in my REST API that will be used to perform some computation. For sake of simplicity, assume that I need to implement a method that for a given list of objects will return its length.
It should only compute the length and return to the client, so no resource will be modified server side. As it does not modify any resources, one would expect that it should be a GET request. However, as the list may be large and the objects may be complex, it looks like I need to make it as a POST request. This would however violate the standard that POST is used in REST to create resources.
What would be your solution to this problem?
First solution
According to RESTful Web Services Cookbook you can treat your computation as a resource and just GET it. For example:
-- Request
GET /computations?param1=2¶m2=2 HTTP/1.1
-- Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": 4
}
It sounds good for fast computations with small amount of input parameters. But if your computation isn't that then you can use second solution.
Second solution
Treat both computation and result as resources. POST computation and GET result. For example:
First you create a computation
-- Request
POST /computations HTTP/1.1
Content-Type: application/json
{
"param1": 2,
"param2": 2
}
-- Response
HTTP/1.1 201 Created
Location: /computations/1
Then you can get this computation
-- Request
GET /computations/1 HTTP/1.1
-- Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"param1": 2,
"param2": 2
}
But also you can get a result (/computations/1/result) of this computation
-- Request
GET /computations/1/result HTTP/1.1
-- Response
HTTP/1.1 204 No Content
Cache-Control: max-age=3600,must-revalidate
But oh no! There is no result yet. Server tells us to come back in an hour (Cache-Control: max-age=3600,must-revalidate) and try again. The second solution allows you to make computation asynchronous (in case when it takes a lot of time) or you can compute it once, store the result in some DB and serve it quickly when requested for the next time.
-- Request
GET /computations/1/result HTTP/1.1
-- Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": 4
}
Pragmatic answer: use POST.
Weasely answer: use POST. Your request contains a resource (or set of resources) that you want the server to temporarily create (the list of objects). If the server happens to delete that resource immediately after the POST has been successfully dealt with, what of it?
The moral of the story here is that with REST you always assume a resource, even if in reality one is not needed and likely not created. In the examples above, what if I want to store neither the computation resource (a JSON object that consists of parameters and some sort of operation) nor the computation result resource? I cannot. I can either
Treat this as a fake resource with GET (pretend that it exists) or
Create two resources with a single POST - one for the computation and one for its result - and then use the corresponding GET to retrieve either of those.
A sneaky assumption here also is that there is NO POST for /computation/<computaiton_id>/result because results are only created via computations.
How should a random number generator properly be implemented in REST?
GET RANDOM/
or..
POST RANDOM/
The server returns a different random number each time.
I can see arguments for both ways.
I'd say this is the same as for a page returned that contains the current time - and many of these are done using GET. Abstractly, fetching a random number (or time) the server's state doesn't change - both time and random numbers can be described as an observation of an external event. E.g. http://random.org use atmospheric noise.
GET seems most appropriate, although caching will need to be disabled via appropriate headers, e.g.
Expires: <Current Time>
Last-Modified: <Current Time>
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
If you want to ensure that the served content is already expired:
To mark a response as "already
expired," an origin server sends an
Expires date that is equal to the Date
header value. (See the rules for
expiration calculations in section
13.2.4.)
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Definitely GET. Even though it might modify server-side state (if it uses a pseudo-RNG), that's just an implementation detail the client shouldn't care about.
definition of REST-call with GET: the result have to be the same -> not GET.
definition of REST-call with PUT: the result of the call can be repeatable, the server should not have problem with it -> use PUT
POST is the weakest method and can used if other are not useful.
Why not GET: the result of GET-call can be cachet (cache-header, etag oder transparent proxies) and you dont will get random results ...