Suppose I have URL as
http://someurl.com/Search?q=a&page=8
(Above mentioned URL is getting called throug AJAX, in MVC4.paging)
What I want is to show only upto http://someurl.com/Search?q=a
I want to hide my second parameter which is page=8
Is this possible?
EDIT: More confusion to add.
<a data-ajax="true" data-ajax-loading="#divLoading" data-ajax-method="POST" data-ajax-mode="replace" data-ajax-success="successPaging" data-ajax-update="#searchresults" href="/Search?q=a&page=1" title="Go to first page"><<</a>
Is button of Next in my Paging, it is making an AJAX request, So I don't know how to change GET to POST for this.
The URL isn't there just for looks; it's telling the server what resource is being requested, and in the case of a query string, that's information the server needs to return a response. http://someurl.com/Search?q=a is a completely different resource than http://someurl.com/Search?q=a&page=8. With a GET request, all you have is the URL, so all the information the server needs must be in the URL. What others in the comments are telling you to do is use a POST request, which among other things includes a post body. In other words, you can pass information to the server both in the URL and in the post body. That allows you to remove the page parameter from the URL and include it in the post body instead. That's the only way you can achieve what you want.
That said, strictly speaking, a POST is inappropriate for fetching a resource like this. POST should be used to update or modify a resource or to call some atomic method in an API scenario. It can also be used for the creation of resources, although PUT is more appropriate there. GET is supposed to be used to return a resource which is not variable. For example, any request to http://someurl.com/Search?q=a&page=8 should always return the same response no matter what client requests it. And, it's even less important what URL is actually being used because the user does not see it at all, since you're requesting it via AJAX (it won't show in the navigation bar). Just keep it as a GET request and leave the parameters as they are.
Related
I have a website built from Ember.js. A user can access a page through URL http://..../view?showTitle=true. However I don't want to explicitly expose the parameter showTitle=true to the user (meaning user will only see http://..../view). This URL is automatically generated and serves as a redirect destination URL. So, I have to remove it manually somewhere before the page load. But I still need this value of this query parameter to query data. Is there a way to achieve that (A example would be great)? What about do it without refreshing the router?
Actually, an example of your scenario would be greater :)
There are some other ways to store data while transitioning to a route. Such as: storing the params in transition object or storing the value in a service. Create a redirection route, use beforeModel hook to grab the value from query params then do a redirection to the real route.
A working example is: ember-twiddle-1
By the way, even if you don't describe your queryParamsin your routes, you can access them via transition.queryParams. This seems a bit hacky. But it works: ember-twiddle-2 (Note: It doesn't work in the same route.)
Updated:
At the setupController hook you can override the controller parameters. So you can remove the parameters from the url. ember-twiddle-3
As we all know, file uploading is most often accomplished using POST method. So, why can't the GET method be used for file uploads instead? Is there a specific prohibition against HTTP GET uploads?
GET requests may contain an entity body
RFC 2616 does not prevent an entity body as part of a GET request. This is often misunderstood because PHP muddies the waters with its poorly-named $_GET superglobal. $_GET technically has nothing to do with the HTTP GET request method -- it's nothing more than a key-value list of url-encoded parameters from the request URI query string. You can access the $_GET array even if the request was made via POST/PUT/etc. Weird, right? Not a very good abstraction, is it?
Why a GET entity body is a bad idea
So what does the spec say about the GET method ... well:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe."
So the important thing with GET is to make sure any GET request is safe. Still, the prohibition is
only "SHOULD NOT" ... technically HTTP still allows a GET requests to result in an action that isn't
strictly based around "retrieval."
Of course, from a semantic standpoint using a method named GET to perform an action other than
"getting" a resource doesn't make very much sense either.
When a GET entity body is flat-out wrong
Regarding idempotence, the spec says:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues)
the side-effects of N > 0 identical requests is the same as for a single request. The methods GET,
HEAD, PUT and DELETE share this property.
This means that a GET method must not have differing side-effects for multiple requests for the
same resource. So, regardless of the entity body present as part of a GET request, the side-effects
must always be the same. In layman's terms this means that if you send a GET with an entity body
100 times the server cannot create 100 new resources. Whether sent once or 100 times the request must
have the same result. This severely limits the usefulness of the GET method for sending entity bodies.
When in doubt, always fall back to the safety/idempotence tests when evaluating the efficacy
of a method and its resulting side-effects.
In case of GET Method
Appends form-data into the URL in name/value pairs and length of URL is limited(3000 characters).
File content can't be put inside a URL parameter using a form.So use POST
In Get method, the value of action, appends a `?' to it, then appends the form data set, encoded using the "application/x-www-form-urlencoded" content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes.
So, that file upload is not possible in GET Method
Shouldn't PUT be used to Create and POST used to Update since PUT is idempotent.
That way multiple PUTs for the same Order will place only one Order?
The difference is that a PUT is for a known resource, and therefor used for updating, as stated here in rfc2616.
The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway to
some other protocol, or a separate entity that accepts annotations. In
contrast, the URI in a PUT request identifies the entity enclosed with
the request -- the user agent knows what URI is intended and the
server MUST NOT attempt to apply the request to some other resource.
I do see where you are coming from based on the names themselves however.
I usually look at POST as it should be the URI that will handle the content of my request (in most cases the params as form values) and thus creating a new resource, and PUT as the URI which is the subject of my request (/users/1234), a resource which already exists.
I believe the nomenclature goes back a long ways, consider the early web. One might want to POST their message to a message board, and then PUT additional content into their message at a later date.
There's no strict correspondence between HTTP methods and CRUD. This is a convention adopted by some frameworks, but it has nothing to do with REST constraints.
A PUT request asks the server to replace whatever is at the given URI with the enclosed representation, completely ignoring the current contents. A good analogy is the mv command in a shell. It creates the new file at the destination if it doesn't exist, or replaces whatever exists. In either case, it completely ignores whatever is in there. You can use this to create, but also to update something, as long as you're sending a complete representation.
POST asks the target resource to process the payload according to predefined rules, so it's the method to use for any operation that isn't already standardized by the HTTP protocol. This means a POST can do anything you want, as long as you're not duplicating functionality from other method -- for instance, using POST for retrieval when you should be using GET -- and you document it properly.
So, you can use both for create and update, depending on the exact circumstances, but with PUT you must have consistent semantics for everything in your API and you can't make partial updates, and with POST you can do anything you want, as long as you document how exactly it works.
PUT should be used for creates if and only if possible URI of the new resource is known for a client. New URI maybe advertised by the service in resource representation. For example service may provide with some kind of submit form and specify action URI on it which can be a pre populated URI of the new resource. In this case yes, if initial PUT request successfully creates resource following PUT request will only replace it.
It's ok to use POST for updates, it was never said that POST is for "create" operations only.
You are trying to correlate CRUD to HTTP, and that doesn't work. The philosophy of HTTP is different, and does not natively correspond to CRUD. The confusion arises because of REST; which does correspond to CRUD. REST uses HTTP, but with additional constraints upon what is allowed. I've prepared this Q & A to explain the HTTP approach to things:
What's being requested?
A POST requests an action upon a collection.
A PUT requests the placement of a resource into a collection.
What kind of object is named in the URI?
The URI of a POST identifies a collection.
The URI of a PUT identifies a resource (within a collection).
How is the object specified in the URI, for POST and PUT respectively?
/collectionId
/collectionId/resourceId
How much freedom does the HTTP protocol grant the collection?
With a POST, the collection is in control.
With a PUT, the requestor is in control (unless request fails).
What guarantees does the HTTP protocol make?
With a POST, the HTTP protocol does not define what is supposed to happen with the collection; the rfc states that the server should "process ... the request according to the [collection's] own specific semantics." (FYI: The rfc uses the confusing phrase "target resource" to mean "collection".) It is up to the server to decide upon a contract that defines what a POST will do.
With a PUT, the HTTP protocol requires that a response of "success" must guarantee that the collection now contains a resource with the ID and content specified by the request.
Can the operation result in the creation of a new resource within the collection?
Yes, or no, depending upon the contract. If the contract is a REST protocol, then insertion is required. When a POST creates a new resource, the response will be 201.
Yes, but that means the requestor is specifying the new ID. This is fine for bulletin boards, but problematic with databases. (Hence, for database applications, PUT will generally not insert, but only update.) When a PUT creates a new resource, the response will be 201.
Is the operation idempotent?
A POST is generally not idempotent. (The server can offer any contract it wishes, but idempotency is generally not part of that contract).
A PUT is required to be idempotent. (The state of the identified resource is idempotent. Side effects outside of that resource are allowed.)
Here is the rfc:
https://www.rfc-editor.org/rfc/rfc7231#section-4.3.3
It depends..
you can create/update sites/records with both.
When the client is specifying the URI then PUT is the way to go.
e.g. Any Code Editor like Dreamweaver, PUT is the right protocol to use.
have also a look at this thread: put vs post in rest
I completely understand the differences between the two in terms of form handling, user discretion and privacy of data, but in what situation would anyone rather use GET over POST when sending form results?
Thanks
W3C HTML 4.01 Recommendation on the appropriate usage of GET and POST:
The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method.
If the service associated with the processing of a form causes side effects (for example, if the form modifies a database or subscription to a service), the "post" method should be used.
Note: The "get" method restricts form data set values to ASCII characters. Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire [ISO10646] character set.
GET places parameters in the URL itself, allowing everyone to see. While POST would be ideal for logins and security-sensitive data, GET is ideal when you want a dynamic page to be bookmarked.
Take a forum for example. The thread which shows all posts within it is loaded dynamically. There doesn't exist a page for every thread available, meaning parameters must be provided which indicate which thread to load. These parameters are passed using GET so that you can bookmark the page and that exact URL with the parameters provided will be used again to load the page.
For instance, to make form data visible in logs.
If i need that user can save a bookmark of next step/page (for whatever reason) i would use GET other than that probably POST.
Both are unsafe and you must escape both.
I use bit.ly to shorten my urls.
My problem - paramters are not passed.
Let me explain I use http://bit.ly/MYiPhoneApps which redirects (let's say) to http://iphone.pp-p.net/default.aspx
Now when I try http://bit.ly/MYiPhoneApps?param=xx this param is not added to the resulting url.
I know I could create an extra "short url" including a paramter - so http://bit.ly/WithParam would result in http://www.mysite.com/somepath/apage.aspx?Par1=yy and so forth.
But what I want is to have a short URL directing to a page - and then I want to add a parameter to this shortened url - which shoul (of course) land at my page.
Is this a shortcome of bit.ly (and others are maybe able to do it) - or does "parameter forwarding" not work with 301 redirections?
Manfred
There's no technical reason why it couldn't be done. The service would simply have to look at what parameters it is being sent, and then rewrite the target URL accordingly.
The problem is that it's not necessarily well defined how to do that.
Suppose you have the url http://example.com/default.aspx?foo=bar, and it has the short url http://foo.com/ABCD. What should happen if you try to access http://foo.com/ABCD?foo=baz? Should it replace the value, so you get foo=baz? Should it append it to make foo=bar&foo=baz? If we include both, which order should they be in?
The system cannot know which parameters are safe to override and which are not, because sometimes, you DO want both of them in the URL, and it may matter what order things are added in.
You could argue "Well, just don't allow this for URLs where parameters are already present", but there's also the issue that it's going to complicate the process a lot more. Without this, you just lookup a key in a database and send a redirect header. Now, you need to also analyze the URL to check for parameters, and append part of the URL you were called by. That requires more system resources per redirect, which may become a big problem if your service is used very frequently - you'll need more server power to handle the same amount of redirects. I don't think that tradeoff is considered to be "worth it".
As mentioned in comments by rinogo and Jurgen
In Clickmeter
Destination URL : www.yoursite.com?myparam1={id1}&myparam2={id2}
Tracking link : www.go.clickmeter.com/38w2?id1=123&id2=abc
After click : www.yoursite.com?myparam1=123&myparam2=abc
In TinyUrl
Destination URL : http://x.com?a=1
Shorten URL : https://tiny url.com/y6gh7ovk
Shorten URL + param : https://tiny url.com/y6gh7ovk?a=2
Resultant URL : http://x.com/?a=1&a=2
Added space to post tinyurl
URL shortening associates a unique key based on a full URL (parameters and all), so it is not possible to pass parameters to a shortening service.
Typically
http://iphone.pp-p.net/default.aspx?param=10
must produce a different key to
http://iphone.pp-p.net/default.aspx?param=22
'Parameter forwarding' is simply not possible in these kinds of redirects, as parameters are not valid parts of a shortened URL is most (if not all) services.