I would like to know why a developer would make a POST request without using a form.
Thanks!
To test the form for one. Then ajax requests can use post data. Also in php at leats you have curl wich I am pretty sure can make use of the post structure to communicate other distant pages.
Because GET and POST do not have the same semantic value. GET requests should be generally safe to perform at any time without compromising the system, while POST requests should be used when doing something important (like accepting a monetary transaction, or, in a less dramatic way, post a comment or something like that).
So it might make sense to make a POST request through AJAX if its result will affect a system.
Source: W3C HTTP/1.1 Method Definitions, read 9.1.1 Safe Methods, 9.3 GET and 9.5 POST. Don't be afraid, it's short and to the point.
Maybe to call a REST API, or other web services that require POST, or to upload a file to a server. You could use AJAX/JavaScript on client side, and just about any server side technology to mimic POST without a form.
POST is an HTTP verb. Browsers use HTTP as its data protocol for fetching HTML data and POST for sending the user submitted data. Basically, any data transfer over http could use POST.
Some of the examples are :
AJAX
REST
etc...
Related
I'm in a situation where I need to execute a POST request only with path parameters and no content.
Since I'm using Spring Boot, I have a #PostMapping annotated method with something like this:
#PostMapping("/firstEntity/{firstEntityId}/secondEntity/{secondEntityId}")
I've read some topics and questions about sending a POST request without body, and found that sending a POST request without body, but with headers isn't a bad practice. It's just uncommon.
But, in that situation where I'm not sending anything nor at the content nor at the headers, is this a bad practice?
For those who are wondering why am I doing this, the fact is that I need to execute a method in my service layer that relates a record from one table with a record from another table.
GET requests can be bookmarked and hit from going to the url in the browser.
POST requests can't be bookmarked and can't be hit from going to the url in the browser.
You're correct in doing this through a POST because you don't want it to be bookmarked or accidentally hit
It is perfectly valid to have a POST with no body and in many circumstances it makes a lot of sense. An alternative would be:
POST /firstEntity/{firstEntityId}/secondEntity
and then supply secondEntityId as the body of that POST.
My question might sound stupid, but I just wanted to be sure:
Is it possible to send an HTTP response before having the request for that resource?
Say for example you have an HTML page index.html that only shows a picture called img.jpg.
Now, if your server knows that a visitor will request the HTML file and then the jpg image every time:
Would it be possible for the server to send the image just after the HTML file to save time?
I know that HTTP is a synchronous protocol, so in theory it should not work, but I just wanted someone to confirm it (or not).
A recent post by Jacques Mattheij, referencing your very question, claims that although HTTP was designed as a synchronous protocol, the implementation was not. In practise the browser (he doesn't specify which exactly) accepts answers to requests have not been sent yet.
On the other hand, if you are looking to something less hacky, you could have a look at :
push techniques that allows the server to send content to the browser. The modern implementation that replace long-polling/Comet "hacks" are the websockets. You may want to have a look at socket.io also.
Alternatively you may want to have a look at client-side routing. Some implementations combine this with caching techniques (like in derby.js I believe).
If someone requests /index.html and you send two responses (one for /index.html and the other for /img.jpg), how do you know the recipient will get the two responses and know what to do with them before the second request goes in?
The problem is not really with the sending. The problem is with the receiver possibly getting unexpected data.
One other issue is that you're denying the client the ability to use HTTP caching tools like If-Modified-Since and If-None-Match (i.e. the client might not want /img.jpg to be sent because it already has a cached copy).
That said, you can approximate the server-push benefits by using Comet techniques. But that is much more involved than simply anticipating incoming HTTP requests.
You'll get a better result by caching resources effectively, i.e. setting proper cache headers and configuring your web server for caching. You can also inline images using base 64 encoding, if that's a specific concern.
You can also look at long polling javascript solutions.
You're looking for server push: it isn't available in HTTP. Protocols like SPDY have it, but you're out of luck if you're restricted to HTTP.
I don't think it is possible to mix .html and image in the same HTTP response. As for sending image data 'immediately', right after the first request - there is a concept of 'static resources' which could be of help (but it will require client to create a new reqest for a specific resource).
There are couple of interesting things mentioned in the the article.
No it is not possible.
The first line of the request holds the resource being requested so you wouldn't know what to respond with unless you examined the bytes (at least one line's worth) of the request first.
No. HTTP is defined as a request/response protocol. One request: one response. Anything else is not HTTP, it is something else, and you would have to specify it properly and implement it completely at both ends.
Is it true that some old proxies/caches will not honor some custom HTTP headers? If so, can you prove it with sections from the HTTP spec or some other information online?
I'm designing a REST API interface. For versioning I'm debating whether to use version as a part of the URL like (/path1/path2/v1 OR /path1/path2?ver=1) OR to use a custom Accepts X-Version header.
I was just reading in O'Reilly's Even Faster Websites about how mainly internet security software, but really anything that has to check the contents of a page, might filter the Accept-Encoding header in order to reduce the CPU time used decompressing and reading the file. The books cites that about 15% of user have this issue.
However, I see no reason why other, custom headers would be filtered. On the other hand, there also isn't really any reason to send it as a header and not with GET is there? It's not really part of the HTTP protocol, it's just your API.
Edit: Also, see the actual section of the book I mention.
Is there any way to determine if a POST endpoint exists without actually sending a POST request?
For GET endpoints, it's not problem to check for 404s, but I'd like to check POST endpoints without triggering whatever action resides on the remote url.
Sending an OPTIONS request may work
It may not be implemented widely but the standard way to do this is via the OPTIONS verb.
WARNING: This should be idempotent but a non-compliant server may do very bad things
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.
More information here
This is not possible by definition.
The URL that you're posting to could be run by anything, and there is no requirement that the server behave consistently.
The best you could do is to send a GET and see what happens; however, this will result in both false positives and false negatives.
You could send a HEAD request, if the server you are calling support it - the response will typically be way smaller than a GET.
Does endpoint = script? It was a little confusing.
I would first point out, why would you be POSTing somewhere if it doesn't exist? It seems a little silly?
Anyway, if there is really some element of uncertainty with your POST URL, you can use cURL, then set the header option in the cURL response. I would suggest that if you do this that you save all validated POSTs if its likely that the POST url would be used again.
You can send your entire POST at the same time as doing the CURL then check to see if its errored out.
I think you probably answered this question yourself in your tags of your question with cURL.
I am not gettng the RESTful thing. Yes, I know how to send a GET request to my app from my browser. It's through URL linking.
<a href="/user/someone">
And can also send POST requests through form method.
<form method="post">
Beside that I know browsers sometimes send HEAD command to figure out page status, but on which the end user has no control.
Then what are those DELETE and PUT commands I am reading of? How do you send, for example a DELETE command from your browser to your RESTful application?
The HTML 4.01 specification describes only GET and POST as valid values for the method attribute. So in HTML there is no way of describing other methods than this by now.
But the HTML 5 specification (currently just a working draft) does name PUT and DELETE as valid values.
Taking a look into the XMLHttpRequest object specification (currently just a working draft too) used for asynchronous requests in JavaScript (AJAX), it supports the PUT and DELETE methods too, but doesn’t say anything about the actual support by current browsers.
To simulate PUT and DELETE, frameworks like Rails instead build forms like this:
<form action="/users/1/delete" method="post">
<input type="hidden" name="_method" value="delete" />
<input type="submit" value="Delete user 1" />
</form>
This is actually a POST form, but using the hidden _method input to tell the server which method was really intended. You could implement this support on any other web framework as well.
#C Moran is right: if you want to be truly RESTful, a browser isn't an ideal client, due in part to the lack HTTP methods beyond GET and POST. However, if you really want to do it from a browser, you can use AJAX to send PUTs and DELETEs, e.g. YUI's Connection Manager allows you specify any of the following HTTP methods:
GET
POST
HEAD
PUT
DELETE
I've heard that DELETE and PUT is not fully supported in all browsers (I didn't check it). Rails is doing workaround - it is sending POST with a hidden field containing real method. So it really uses only GET and POST and on server it reads this hidden field and reacts on it.
A POST doesn't have to be through a form. The best way to learn about this, and also GET, PUT and DELETE is to use a ReST client to make your HTTP requests and see the responses. I recommend you download the nifty little python client from http://restclient.org/
A browser is (as of now) not your best tool to use while you are acquainting yourself with ReST. A client like the one above will allow you to "see" your HTTP requests and responses.
Flash based applications (or Flex) can work on lower levels, like open sockets. They can also do PUT/DELETE (though Flex in particular is known to have problems with http headers.
So I guess I'm saying it depends on your client technology. In particular, you could embed a small flash object that would do the communication for you if your browser doesn't support it (or you don't want to implement cross-browser support).
DELETE and PUT are HTTP verbs, say REST commands that shall delete or update an object on the server.
Using them in the browser can be done in different ways. You can't send them through HTML, but you can send an JavaScript Ajax request, if you want to use them programmatically.
If you only want to explore the API or test some calls, and you want to do this from the browser, you can use browser plugins like RESTED for firefox.
For manual and automatic testing you can use Postman as a full featured API test environment.
On Windows, you can use the PowerShell script httprepl to send different HTTP RESTful API usages.