Rfc2616 lists many methods besides GET and POST, like, say, DELETE, PUT etc. Method field in html forms, though, seems to be allowed to specify only GET or POST.
Is it possible to create a link or form in a html page that uses a request method that is not GET or POST?
Was trying to figure this out for a rails app that was using Angular on the front end; these seems to work for that environment:
<a data-confirm="Are you sure?" data-method="delete" href="/link-to-resource" rel="nofollow">Delete</a>
Edit: Just to give everyone a heads up, I think you still need to have jQuery for this to work. I removed jQuery and it stopped working; I put it back and it started working.
You certainly can’t create a link that uses anything other than GET. Since HTML began, links have been meant to be idempotent and free from side effects.
For forms and XMLHTTPRequests, Caps’ link is the place to look: Are the PUT, DELETE, HEAD, etc methods available in most web browsers?.
By default, not there is no way to do this. Links always perform GETs, forms can use GETs or POSTs.
That said, with a little JavaScript, it's possible. Rails for instance ships with helpers which will add a data-method attribute to links. Rails-UJS is a jQuery library that will transparently intercept clicks on these links, and trigger a form submit with a _method parameter used for overriding the normal HTTP method. Finally Rack will intercept requests with a _method params, and overwrite the request method with the value in _method.
Other frameworks no doubt follow a similar pattern.
If you want even more details, I've written up an explanation of how Rails, Rails-UJS, and Rack all work together to provide this.
It's good to know how your libraries work.
It is not possible to create a link or form with delete method.
Many web framework create a hidden input called "_method" for handling PUT and DELETE.
I created a plugin for automatically convert links to forms : RestfulizerJs
You can take a look here : https://github.com/Ifnot/RestfulizerJs
#Ifnot plugin is great but I created a one based on $.ajax function instead of appending hidden forms! here's a simple example for a DELETE request
HTML
<button class="delete" data-target="http://example.com/post/post-id/" data-method="DELETE" data-disabled="true">Delete Article</button>
JavaScript
$(".delete").restintag(optionsObj, function(data) {
console.log(data);
},
function(error) {
console.log(error);
});
https://github.com/KhaledElAnsari/RESTInTag/
HTMX is designed to solve this.
Why should only <a> and <form> be able to make HTTP requests?
Why should only click & submit events trigger them? Why
should only GET & POST methods be available? Why should you only be
able to replace the entire screen? By removing these arbitrary
constraints, htmx completes HTML as a hypertext
It enables any DOM element to make HTTP requests GET, POST, PUT, PATCH, and DELETE, without writing any custom JavaScript.
just add a data-method attribute,<a data-method='put' href='whatever'>link</a>
Related
I am volunteering on a website-based project that is trying to make all pages fully operable JavaScript free before adding any JavaScript for enhancements, and I was asked to investigate whether or not a particular scenario could be handled purely through HTML/CSS.
What we have is a form that is populated to help us filter a list of tickets that are displayed on the screen after a page update through a GET action, which itself works fine, but the concern with the current implementation is that the URL cannot be made into a permanent link. The request, however, to keep the permanent link as minimal as possible, is to only send GET parameters for fields that are populated with something (so, suppressing GET parameters for fields that are blank) instead of having a different GET parameter for each form field on the page.
I have thought of several ways that could be done, most including JavaScript (example: create fields with ids but no names and a hidden field w/ name that uses JS to grab the data from the fields), but also one that would be a POST action with a redirect back to the GET with a human readable string that could be permanently used. The lead dev, however would prefer not to go through the POST/redirect method if at all possible.
That being said, I'm trying to make sure I cover all my bases and ask experts their thoughts on this before I strongly push for the POST/redirect solution: Is there a way using only HTML & CSS to directly suppress GET parameters of a form for fields that are blank without using a POST/redirect?
No, suppressing fields from being submitted in an HTML form with method of "GET" is not possible without using JavaScript, or instead submitting the form with a POST method and using a server side function to minimize the form.
What fields are submitted are defined by the HTML specification and HTML and CSS alone cannot modify this behavior and still have the browser be compliant with the standards.
No, you cannot programmatically suppress any default browser behavior without using some kind of client scripting language, like JavaScript.
As a side note, you say "JavaScript for enhancements", but JavaScript is not used for enhancements these days. And no one in the real world would except a decent front-end without the use of JavaScript. I would suggest you simply use JavaScript.
I do not think you can avoid Javascript here to pre process before submission to eliminate unchanged /empty form fields.
I am certain the answer will be 'NO', but I wanted to ask anyway just
incase I have missed something.
Everyone knows that one pass data to a page in an anchor tag by using
the GET method:
What I am wondering is if there was a way to do the same thing, but use
the POST Method instead?
My purpose in doing so is to keep the URLs the user sees clean by not
putting anything in them that they do not need to see.
This has nothing to do with security concerns as I already know there
would be ways to obtain the data being passed.
If the answer is indeed no, then what methods do people use to pass data
when there is a desire to keep the URLs clean? Cookies? Something else?
and how to deal with the scenarios when the URL length exceeds the permissible GET request length
I am facing this issue while implementing sorting/pagination with displaytag, all the request parameters are appending in the sort/pagination url which is more then the permissible length of the GET request.
You could do something like this:
<form method="post" action="target.html">
<input type="hidden" name="name" value="value" />
<a onclick="this.parentNode.submit();">click here</a>
</form>
This behaviour is specific to display tag library. It allows for easily bookmarkable search results. If you really intend to change this to make use of POST, then you'd need to rewrite the display tag library or bring in some jQuery to manipulate the links.
The remnant of your questions boils nowhere. If you want GET (idempotent requests, bookmarkable URLs, searchbot-crawable URLs, etc), then use GET. If you want POST (non-idempotent requests, non-bookmarkable URLs, non-crawlable URLs, etc), then use POST.
Usually, POST is mandatory when the request can modify the data in the server. Think of a SQL INSERT, UPDATE, DELETE, etc. You certainly won't make this kind of requests GET. Imagine that you've a table with all "delete row" links which do GET and then a searchbot comes along...
You can use javascript. On onclick of link do form.submit
The only way I know of to deal with lenghty URL is to instead use POST.
You may create a temporary form and submit it while onclick event of <a> tag.
It will work as post ,the name value can be through anchor tag and value of name="" can be access to $_POST[] globl var
How can I link to a page and make the browser call it with the DELETE method, as Rails does?
I tried DELETE MEbut doesn`t work.
I use Node.js, so I can use it to handle DELETE method.
You can't. Links will only ever trigger a GET request.
You can choose between a GET and a POST in a form.
Other HTTP request types can be made using JavaScript and XMLHttpRequest, but not reliably cross-browser.
You can use a javascript plugin like RestfulizerJs for converting your links to pseudo forms.
I am trying to simply post an entire form w/o the need to create the url like you would have to in a get call. All of the tutorials I have seen for this for some reason create a parameter URL and send it via the send ability.
I want to be able to send a form via the form id or form name, is this possible?
The reason is because I will have some submits that can have anywhere from 2 to 1000 checkboxes the user can press (not my choice).
Example I looked at mainly is: http://www.captain.at/howto-ajax-form-post-request.php
I use a type="button" to do the submit not a onchange or anything like that.
Use jQuery, and it's very easy:
$.post("/myactionpage.php",$("#formID").serialize(), function (data) { whatever(); });
If you can use jQuery, the JQuery Form plugin does exactly that.
The jQuery Form Plugin allows you to easily and unobtrusively upgrade HTML forms to use AJAX. The main methods, ajaxForm and ajaxSubmit, gather information from the form element to determine how to manage the submit process.
There are multiple ways to do this and you're right, you don't want to use the GET method. You want to use the POST method, which allows you to send all the data in the form. There are too many options to list, but jQuery is a good start. If you don't want to use an external library like jQuery, try checking out a google search on "ajax via post".
I read some AJAX-Form tutorial like this. The tag form is used in HTML code. However, I believed that it is not necessary. Since we send HTTP request through XmlHttpRequest, the sent data can be anything, not necessary input in form.
So, is there any reason to have form tag in HTML for AJAX application?
Apart from progressive enhancement as already discussed (don't make your site require JavaScript until it really has to), a <form> with onsubmit would be necessary to reliably catch an Enter keypress submission.
(Sure, you can try trapping keypresses on separate form fields, but it's fiddly, fragile and will never 100% reproduce the browser's native behaviour over what constitutes a form submission.)
Sometimes, web apps using ajax to transform their data either use forms as a fallback when the user has no JavaScript enabled (a sometimes expensive but very good thing to do).
Otherwise, if an application builds and sends an AJAX request, there is no compelling reason to use a form except in rare special cases when you actually need a form element. Off the top of my head:
when using jQuery's form serialize function
when monitoring all fields in a form for changes
when there is need to make use of the reset form button (that to my knowledge is available in a proper <form> only).
I see at least two possible reasons :
Graceful degradation (see also Unobtrusive JavaScript) : if a user doesn't have Javascript enabled in his browser, your website should still work, with plain-old HTML.
Behavior of the browser : users know what forms look like and how they behave (auto-completion, error-correction, ...) ; it's best not going too far away from that
And I would add that, if you want the user to input some data, that's why <form> and <input> tags exist ;-)
Using the right tags also helps users -- as an example, think about blind users who are navigating with some specific software : those software will probably have a specific behavior for forms an input fields.
It really depends what you're doing. If you're wanting to take form content submitted by the user and use AJAX to send that somewhere then you're going to want to use the form tag so your user can enter their data somewhere.
There will be other times when you're not sending data from a form and in that case, you wont have a form to be concerned about :)