I am sending the Market Request on the FIX server as:
Request:
FIXT.1.1:135->PSE, outgoing> (8=FIXT.1.1|9=173|35=D|34=43|49=135|52=20200213-06:30:47.204|56=PSE|1=11011000000035|11=1581575447212|38=1000|40=1|54=1|55=PIZZA|59=0|60=20200213-14:30:47.204|453=1|448=13501100|447=C|452=12|10=048|)
In the request I am sending the 40 tag i.e(Order Type)=1 and had recieved the following response with the error as:
Response:
FIXT.1.1:135->PSE, incoming> (8=FIXT.1.1|9=000353|35=8|49=PSE|56=135|34=43|57=13501100|52=20200213-06:30:47.318|37=NONE|11=1581575447212|453=4|448=13501999|447=C|452=11|448=13501999|447=C|452=36|448=13501100|447=C|452=12|448=135|447=C|452=1|17=1808|150=8|39=8|103=99|1=11011000000035|55=PIZZA|54=1|38=1000|59=0|528=A|151=0|14=0|60=20200213-06:30:47.116|58=(243): Market orders not accepted at this time|10=101|)
The request is send according to the documentary of the FIX server, so please let me know what changes should be made in the request for getting the proper response??
Related
I am trying to use a REST Service as a Sink Dataset in my Dataflow, but it always fails with a Bad Request 400 Error.
Error
{"StatusCode":"DFExecutorUserError","Message":"Job failed due to reason: DF-REST_001 - Rest - Error response received from the server (url:https://my_url,request body: Some({"Name":"GREST"}), request method: POST, status code: 400), response body: Some({"error":{"name":"badRequest","message":"Request body has invalid format."}}))","Details":"com.microsoft.dataflow.Issues: DF-REST_001 - Rest - Error response received from the server (url:https://my_url,request body: Some({"Name":"GREST"}), request method: POST, status code: 400), response body: Some({"error":{"name":"badRequest","message":"Request body has invalid format."}}))\n\tat com.microsoft.dataflow.Utils$.failure(Utils.scala:75)\n\tat org.apache.spark.sql.execution.datasources.rest.RestClient.ensureSuccessResponse(RestClient.scala:430)\n\tat org.apache.spark.sql.execution.datasources.rest.RestClient.org$apache$spark$sql$execution$datasources$rest$RestClient$$executeRequest(RestClient.scala:415)\n\tat org.apache.spark.sql.execution.datasources.rest.RestClient.org$apache$spark$sql$execution$datasources$rest$RestClient$$executeSingleRowRequest(RestClient.scala:153)\n\tat org.apache.spark.sql.execution.datasources.rest.RestClient$$anonfun$savePartitionSingle$1$$anonfun$apply$mcV$sp$3.apply(RestClient.scala:106)\n\tat org.apache.spark.sql.execution.datasource"}
The status code 400 is a Bad Request error, and the server cannot process the request due to an error.
The possible reasons might be due to incorrect URL, malformed syntax, request body might have invalid JSON. Please check the URL and validate JSON data.
When you use copy activity and the method is POST, make sure that you send it in Additional headers section key -> "Content-Type" value -> "application-json"
I'm writing a C# Web API server application, and will send JSON to it via a Mirth HTTP Sender destination. This post is about how to handle error conditions. Specifically, there are three scenarios I want to handle:
Sometimes we take the C# application server offline for a short period for system upgrade or maintenance, and Mirth is unable to connect at all. I want Mirth to queue all messages in order, and when the server is available, process them in the order they were received.
The server receives the request, but rejects it due to a problem with the content of the request, e.g., missing a required field. In accordance with REST conventions, the server will return a 400-level HTTP response. This message would be rejected every time it's submitted, so it should not be re-sent; just log the failure and move on to the next message.
The server receives the request, but something goes wrong on the server, and the server returns an HTTP 500 Server Error response. This would be the appropriate response, for example, when something in the server environment has gone wrong. One real-world example was the time the Web API server was running, but somebody rebooted the database server. REST conventions would suggest we continue to resend the message until the transient problem has been resolved.
For #1, initially I had it queue on failure/always, but it appears the response transformer never runs for messages that were queued (at least, the debug statements never showed in the log). I have turned queueing off, and set it to retry every ten seconds for an hour, and that seems to give the desired behavior. Am I on the right track here, or missing something?
For #2 and #3, returning any HTTP 400 or 500 error invokes the 1-hour retries. What I want is to apply the 1-hour retries for the 500 errors, but not the 400 errors. I’ve tried responseStatus = SENT in the response transformer, but the response transformer only runs once, after the hour has expired, and not for each retry.
This seems like a common problem, yet I’m not finding a solution. How are the rest of you handling this?
You're close!
So by default, the response transformer will only run if there's a response payload to transform. For connection problems, or possibly for 4xx/5xx responses that contain no payload, the response transformer won't execute.
However, if you set your response data types (From the Summary -> Set Data Types dialog, or from the Destinations -> Edit Response, Message Templates tab) to Raw, then the response transformer will execute all the time. The reason being that the Raw data type considers even an empty payload to be "transformable".
So turn queuing back on, and set your response data types to Raw. Then in the response transformer, if you look at the Reference tab there's a category for HTTP Sender:
You'll want the "response status line", that's the "HTTP/1.1 200 OK" line of the response that contains the response code. Here's a response transformer script that forces 4xx responses to error:
if (responseStatus == QUEUED) {
var statusLine = $('responseStatusLine');
if (statusLine) {
var parts = statusLine.split(' ');
if (parts.length >= 2) {
var responseCode = parseInt(parts[1], 10);
// Force 4xx responses to error
if (responseCode >= 400 && responseCode < 500) {
responseStatus = ERROR;
responseStatusMessage = statusLine;
}
}
}
}
im currently working on a website which has Spring at backend and Angularjs at front side and we had discussed about back end responses to handle frontend's message dialogs and i have a question to ask:
Lets say i have an API :
GET : /getstatistics
Request params : fromTime,toTime ( in timestamp format)
And if client make a request with invalid params like a string, which response code should be returned from server ? HTTP 400 bad request and response body with a message " fromTime and toTime should be in timestamp format" or HTTP 200 with same message?
I saw some Google's APIs for example Oauth, they're returning code 200 for a request with invalid access_token but ,in our project my opinion it should be HTTP 400 because Javascript has success and error callbacks, is it better for it just pop a red color dialog with message inside rather than a HTTP 200 code then still need to check the content of the message?
Any advides and opinions are appreciated.
Thanks!
You should be returning a 400 error for bad request. Check out this reference.
The server cannot or will not process the request due to something
that is perceived to be a client error (e.g., malformed request
syntax, invalid request message framing, or deceptive request
routing).
Please have a look at RFC7231#section-6
A client MUST understand the class of any status code, as indicated by
the first digit
and,
4xx (Client Error): The request contains bad syntax or cannot be
fulfilled
Bad syntax can be something like you've mentioned in your question (making a request with invalid parameters, like a string).
I keep these two references handy whenever I'm designing RESTful APIs, might be helpful for you too:
https://httpstatuses.com/
http://www.restapitutorial.com/httpstatuscodes.html
Yes you are right, the http code should be 400 in your case. Your discussion here normally should be whether you need to return 400 or 422. For this you can check the accepted response for this SO question 400 vs 422 response to POST of data
I think it has something to do with how the parameters are used. If you use the resource, then a 404 should return. If the data is simply not valid then we decide to set a 409 Status to the request. It can't full fill it at 100% because of missing/invalid parameter.
HTTP Status Code "409 Conflict" was for us a good try because it's
definition require to include enough information for the user to
recognize the source of the conflict.
Reference: w3.org/Protocols/
Edit:
In any case, the status code 200 is incorrect here because there is an error. In response, you can then return specific information like this:
{
"errors": [
{
"userMessage": "Sorry, the parameter xxx is not valid",
"internalMessage": "Invalid Time",
"code": 34,
"more info": "http://localhost/"
}
]
}
I have a bunch of PUT operations which execute actions on the input resource.
Let's make an example: I have a payment operation in my API which state that a credit card must be charged by a specific Amount.
In my code I first verify if there is sufficient credit on the card and then execute the operation. If there is'nt sufficient amount I simply return 400 but I am not sure it is correct.
Which is the correct HTTP Status Code in cases like this?
I can, of course send a response with HTTP 200 and attach a payload with further details explaining the error. I can also send back an HTTP 400 Bad Request or even better an HTTP 412 Precondition Failed.
Which is the correct code to send in the response in scenario like this where the validation failed? Is there any resource that I can read to understand the rationale behind HTTP Status Codes and HTTP Verbs?
Use 422 Unprocessable Entity.
The 422 status code means the server understands the content type of the request entity (hence a 415 Unsupported Media Type status code is inappropriate), and the syntax of the request entity is correct (thus a 400 Bad Request status code is inappropriate) but was unable to process the contained instructions.
Failing that, simply use 400 for any error having to do with your business domain. As of June 2004, the description for error 400 was amended to read:
The server cannot or will not process the request due to something that is perceived to be a client error
If the operation failed because of data sent by the user (it seems to be the case), you should use status codes 400 (general) or 422 (more precise but coming from the WebDAV spec). You can return back additional hints about the error within the payload (the structure is up to you) like:
{
error: {
"field": "amount",
"message": "The amount isn't correct - Sufficient credit."
}
}
I think that code 412 doesn't apply here since it must be returned when your server doesn't meet a condition specified by the client (see headers If-* like If-Match, If-Modified-Since, ...).
Hope it helps you,
Thierry
IMO: I would stick with 200 and then parse out the response and deal with that. HTTP status codes are protocol status code, not something that you should use for dealing with application logic.
{
"error": {
"field": "amount",
"message": "The amount isn't correct - Sufficient credit."
}
}
In case of the above code, the service call worked fine warranting a return code 200. However, you application logic now needs to deal with the error reported.
If we are using a HTTP status code to indicate error, we will start to get flagged in our logs etc. even though there was no technical error.
What status code should a REST service return in response to a POST request containing a malformed / unparseable message body?
400 Bad Request
Straight from the specification:
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
Alternatively, if you need a more specific status you can create your own 4XX status for whatever API you might be designing.
400 - Bad Request
From Hypertext Transfer Protocol -- HTTP/1.1 (RFC-2616):
400 Bad Request
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
I'd say 412 Precondition Failed