When using "Response.PermanentRedirect"
It will return back Http Response Code 301 which means permanent redirection to diferent location. This may not be any value for end user using the browser but for search engines it will help the search engines not to index permanently redirected urls.
Question - Does Delete Verb in MVC perform the same function ?
Post a new entity as an addition to a URI. Put replaces an entity that is identified by a URI.
Question - When performing the insert/update, the information is being submitted in both cases. Does it means in case of Insert, Post verb should be used and in case of Update Put verb should be used ?
To answer your first question :
From the RESTful API point of view DELETE must be used to remove a resource from its parent which is often a collection or store. Once a DELETE request has been processed for a given resource, the resource can no longer be found by clients. Therefore, any future attempt to retrieve the resource’s state representation, using either GET or HEAD, must result in a 404 (“Not Found”) status returned by the API.
The DELETE method has very specific semantics in HTTP, which must not be overloaded or stretched by a REST API’s design. Specifically, an API should not distort the intended meaning of DELETE by mapping it to a lesser action that leaves the resource, and its URI, available to clients.
204 (“No Content”) should be used in response to a PUT, POST, or DELETE request
Response.PermanentRedirect indicates that the REST API’s resource model has been significantly
redesigned and a new permanent URI has been assigned to the client’s requested resource.
The REST API should specify the new URI in the response’s Location header.
301 (“Moved Permanently”) should be used to relocate resources
For the Post and Put :
PUT must be used to add a new resource, with a URI specified by the client and must also be used to update or replace an already stored resource. PUT must be also used to update mutable resources while POST must be used to create a new resource in a collection.
Related
I am trying to implement a REST-ful API using Vapor 3, and I'd prefer to use what seems like a fairly standard creation pattern in other web frameworks: I'd like the entity creation controllers to return a 201 Created response status, with a Location response header that contains the full URL of the newly-created resource.
All of the Vapor 3 documentation I can find shows a create pattern that instead returns a 200 OK status, and includes the full resource in the response body. But I can't find any examples that use a 201 response even though that tends to be the more standard REST-ful API approach in my experience.
I have found that I can manually create a 201 response in my controller, and I assume there's a way to set arbitrary headers in that response. If so, is there a convenient way of getting the full URL of the resource I've just created so that I can set a Location header in the response?
I'm sure there are ways I can "brute force" this to get what I want but I am hoping that Vapor defines an idiomatic way to do this, much like the Java and Rails frameworks I've used provide.
Since you are manually creating a response, you are right, adding an arbitrary header is simple.
I assume you are following the standard CRUD route structure, so if you have a User model, you have the following routes:
POST /users
GET /users/:user
PATCH /users/:user
DELETE /users/:user
The important part here is that we know that the URL to get the user is the URL to create a user, plus the user's ID. If this is the case, we can create a location header like this:
user.save(on: req).map { user in
let http = HTTPResponse(...)
let location = req.http.url.path + "/" + user.id.description
http.headers.replaceOrAdd(name: "Location", value: location)
return Response(http: http, container: req)
}
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.
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
Which browser support REST completely?
Means Get,Post,PUT and DELETE method?
I understood the rails way to understand PUT and DELETE is "_method" hidden variable like
<form id="form_id" action="" method="PUT" >
-- form content --
</form>
method="PUT"?
Or am I thinking wrong?
In many REST frameworks calling the HTTP PUT or DELETE operations from a browser can be achieved through what is known as an "Overloaded POST". What this means is you submit the request from the browser to the server as a POST request with some information appended to the URL specifying the actual HTTP method that should be used.
I know that the Restlet framework for Java follows this approach and I believe Rails does as well.
So if you have a REST API defineed like this:
POST - http://myservice/myobject -> creates a new object and
returns the object id
GET - http://myservice/myobject/id ->
returns the object
PUT - http://myservice/myobject/id ->
updates the object
DELETE - http://myservice/myobject/id ->
deletes the object
using Overloaded POST from the browser you could also
POST - http://myservice/myobject/id?method=PUT -> updates the object
POST - http://myservice/myobject/id?method=DELETE -> deletes the object
In fact, for Flex which does not support PUT or DELETE, this is the only way to call these REST operations.
This question is almost the same as this one: Are the PUT, DELETE, HEAD, etc methods available in most web browsers?,
see there for a great answer.
Also, "GET, POST, PUT and DELETE" is not "REST". All four are different methods in the HTTP specification, REST is an architectural style that uses those four.
PUT and DELETE are just specifications, and are not implemented by any browser and web server.
So donot design RESTful web service with support for PUT or DELETE if you are sending request.