I am designing a RESTful API and am using the usual HTTP status codes like 200, 404, 500, etc.
Given the situation where occasionally the API will require additional data. When this event arises it needs to respond with a relevant status code so that the client application can present the relevant user interface.
Example:
User fills in form and hits submit (using AJAX)
Server sends response with some status code to indicate that further information is required which is accompanied with additional user interface.
Additional user interface is displayed
User resubmits form
I have this working with a 200 status code, but I would prefer to use a different status code so that my AJAX handler can detect and handle this scenario automatically.
Are there any relevant status codes or would I need to use a sub status code which is returned as a part of my JSON response?
I would go with a 400 Bad Request, since there is more data needed.
Alternatively, a 100 Continue could also work.
Either of those codes indicates that more info is needed.
how about 202 Accepted
"The request has been accepted for processing, but the processing has not been completed"
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
I would suggest 412 Precondition Failed.
Related
I have Zabbix server 5.0 and I should check an availability of Outlook authorization.
I'm trying to make a Web scenario with 2 steps:
Checking of the authorization page.
I use https://<domain_name>/owa but it is redirected to https://<domain_name>/owa/auth/logon.aspx?replaceCurrent=1&url=https%3a%2f%2f<domain_name>%2fowa%2f. I tick "Follow redirects" and get status code 200.
https://i.stack.imgur.com/Pzmhp.jpg
Trying of authorization.
I use the same URL that I was redirected to in the first step, also I input this in Raw Post
destination=https%3A%2F%2F<domain_name>%2Fowa&flags=4&forcedownlevel=0&username=&password=&isUtf8=1 (I can use Form Data too). But if I input an invalid password and username, status code in response is 200 too (screens are below). I think it's because of redirections: authorization is not done and I was redirected at the same page.
https://i.stack.imgur.com/wVAwa.jpg
https://i.stack.imgur.com/9ddgp.jpg
After this step is finished I get status code 200 always.
How to do it correctly?
Add a string check to the scenario you already created. Look for a string that is present only after a successful login.
Required regular expression pattern.
Unless retrieved content (HTML) matches the required pattern the step will fail. If empty, no check on required string is performed.
https://www.zabbix.com/documentation/4.2/manual/web_monitoring
In a classic form-based webapp, if a user submits a HTML form that contains validation errors, assuming no JavaScript, what's the correct thing to do?
Respond with the HTTP 200 + the page content (including error info for the user)
Respond with the HTTP 400 + the page content (including error info for the user)
Does it matter?
Your app is talking to human beings, not other machines. Therefore you should do the right thing and handle exceptions in a user-friendly manner.
Your user doesn't care about HTTP return codes, and so it should not even be a consideration for you either. You are confusing business-logic problems with HTTP protocol problems.
Infact, by throwing a 400 error at a web-browser, you are only likely to encounter the web browser throwing up an ugly message to the user.
If you were coding a REST api, then the answer would be different. But you're not.
1) would be the correct approach because you want to display a page of content to the user that highlights the invalid input values.
The trouble with 2) is that some browsers may display their own 'friendly' error page that is designed to help users understand 4xx errors. Here's some information about when IE displays 'friendly' error pages:
http://support.microsoft.com/kb/294807
On the one hand, if it is a web app for human consumption, a 200 with a some useful error message will work. Making web sites for humans is easier in that sense because they can read and understand the content and do not have to depend on the status code for interact with the applications.
On the other hand, If you thinking of a REST API more appropriate would be to throw a 4xx error because it is a client side error. In that case, you have several options.
According RFC2616, a 400 means
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
This doesn't seem to be appropriate as it's not due to malformed syntax.
However, RFC2616 is now obsoleted by RFC7230-7235. The new RFC7231 defines the meaning of 400 in a more broader way.
Client Error 4xx The 4xx (Client Error) class of status code indicates
that the client seems to have erred. Except when responding to a HEAD
request, the server SHOULD send a representation containing an
explanation of the error situation, and whether it is a temporary or
permanent condition.
400 Bad Request
The 400 (Bad Request) status code indicates that 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)
So this seems acceptable even though still generic. Another option would be to use 422 status code defined by RFC4918 (WebDAV).
422 Unprocessable Entity The 422 (Unprocessable Entity) 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. For example, this error condition may occur
if an XML request body contains well-formed (i.e., syntactically
correct), but semantically erroneous, XML instructions.
Why if I submit an URL like:
localhost:38245/TeamWork/Group/1/LONG-COMMENT-POSTED-BY-USER ,
I get an error that says "Bad Request - invalid URL HTTP Error 400. The request URL is invalid." ?
The default maximum length of a URL is 4096 in IIS. You may well be breaching that with the comment posted by the user. Generally, the best way to transfer that kind of data is by POST rather than in a URL. You can either trim the comment to a more suitable size of increase the maxUrl value in the requestLimits section of your IIS config: http://msdn.microsoft.com/en-us/library/ms689462%28v=vs.90%29.aspx
Firstly, HTTP 400 error is intended for cases when the client has made an error. As you've noticed yourself it's a bad request error. So that means possibly due to bad syntax the request can not be carried out. As Mike Brind mentions, you're most probably exceeding the maximum length of the URL (the default value anyway)
Secondly, why are you trying to "submit" a long post by URL? Use the POST method instead. A way to do this is by using Jquery's Post method to do this. See this. Or simply by calling the form's submit method through OnClick method or however the user is submitting the form.
POST is perfect for transmitting large amounts of data. So submitting data from the client side, the easiest way by far is to use POST to archieve this.
As you have yourself stated in the Question code part,
localhost:38245/TeamWork/Group/1/LONG-COMMENT-POSTED-BY-USER
the Long comment by user, must be inside the limits that are in the web.config file of your website.
Secondly, no Server would allow a very Long Url thinking that the user might be trying to post a malware. Also, using short URLs is good for Data transfer as they consume less data.
From the limits on Requests one would easily come to understand that the URL must be less than 4096bytes, only 4KB. So do you think, all that URL would be 4KB?
As Mike has suggested to use POST request to send the long data, I would also suggest you to use HttpPost requests to send this type of long data. This way, Browser would encrypt the data and sending it as an attachment to the request.
I have a Student add REST api call. This allows candidate data as well as file attachment.
Lets say, candidate is added successfully and but the document was not uploaded for some reason.
what should be the response status code.
if both are successful, I am returning 200 with the newly created candidate JSON object.
REST API calls should be successful or fail. No half-ways.
If it's not mandatory for creation of account to upload an attachmment, it should be done in a separate call. If an attachment is mandatory (or if provided it's mandatory that it should upload), the request should fail, no user get created and then return a 4xx status code indicating the issue.
Assuming it's not mandatory, I would separate this into 2 different REST calls. Trying to overload too much functionality into one call starts making your api gets messy. I'd recommend creating one call create the user and a second to associate files to the user. Then you just use 201 (created for the new user) and 200 (for successful association of the document) response codes.
One other option: gracefully ignore the failure, create the user, return a 201 and live with the lost attachment :)
I know that there are two methods of submitting a form: 'GET' and 'POST'. We can also use request method for accessing the content of the submitted.
I want to know whether there is any other method of submitting the form. As far as my knowledge there are only two methods. But some one asked me this question in a interview that there are 5 method of submitting the form.
If any one has any idea about this please tell me.
The question was probably about HTTP request methods. There 9 request methods:
HTTP defines nine methods (sometimes referred to as "verbs")
indicating the desired action to be performed on the identified
resource. What this resource represents, whether pre-existing data or
data that is generated dynamically, depends on the implementation of
the server. Often, the resource corresponds to a file or the output of
an executable residing on the server.
HEAD: Asks for the response identical to the one that would
correspond to a GET request, but without the response body. This is
useful for retrieving meta-information written in response headers,
without having to transport the entire content.
GET: Requests a representation of the specified resource. Requests
using GET (and a few other HTTP methods) "SHOULD NOT have the
significance of taking an action other than retrieval". The W3C has
published guidance principles on this distinction, saying, "Web
application design should be informed by the above principles, but
also by the relevant limitations." See safe methods below.
POST: Submits data to be processed (e.g., from an HTML form) to
the identified resource. The data is included in the body of the
request. This may result in the creation of a new resource or the
updates of existing resources or both.
PUT: Uploads a representation of the specified resource.
DELETE: Deletes the specified resource.
TRACE: Echoes back the received request, so that a client can see
what (if any) changes or additions have been made by intermediate
servers.
OPTIONS: Returns the HTTP methods that the server supports for
specified URL. This can be used to check the functionality of a web
server by requesting '*' instead of a specific resource.
CONNECT: Converts the request connection to a transparent TCP/IP
tunnel, usually to facilitate SSL-encrypted communication (HTTPS)
through an unencrypted HTTP proxy.
PATCH: Is used to apply partial modifications to a resource.
HTTP servers are required to implement at least the GET and HEAD
methods
The HTML form element's method only accepts two parameters, GET and POST. Evidenced by this entry on the W3 Standards site:
method (GET|POST) GET -- HTTP method used to submit the form--
They may have been asking you about ways to submit the data. In which case there are many more, like AJAX, Flash, P2P types, etc.
However if they specifically said FORM, as in the HTML FORM element -- then no. POST and GET.
Addendum: Here is a StackOverflow question asked on a similar topic. In that the answerer highlights other methods which can be submitted via AJAX. Again, though, note that these are down through AJAX and not strictly through the FORM element.