just a short question:
Having the new instance of a model and issuing a model.save() with URL set to /api/store/category, Backbone issues a POST. According to my knowledge, it should use PUT, like mentioned in this "PUT or POST: The REST of the Story" blog post.
Who is right? BB or this article's author?
According to Backbone documentation, saving a new model will result in a POST request, and saving an existing model (having an id) will emit a PUT request.
save model.save([attributes], [options])
...
If the model isNew, the save will be a "create" (HTTP POST), if the model already
exists on the server, the save will be an "update" (HTTP PUT).
And if you are wondering if Backbone should use a POST for creation, check
PUT vs POST in REST
RESTful web services on Wikipedia
In the light of these articles, I'd say that, in the context of Backbone, the verbs are correctly used:
saving a new model causes a change in the system, a new URL is added, the action is not idempotent, it should be a POST,
saving a known model replaces a resource at a given URL, the action is idempotent, it should be a PUT.
Related
My question: When using AJAX within Rails, from a best practice standpoint, does the HTML verb that I use (e.g., get) to define a route matter? Is it OK to basically always use get?
Context: In my Rails App, I've built the following:
When a user selects an HTML checkbox, that triggers a JQuery listener that lives in a file inside of /app/assets/javascripts.
This .js file makes an AJAX call to a controller/action: foos#bar. My JS passes an ID into the action.
To route this request, I've added the following to routes.rb: get "/foos/bar" => "foos#bar". This tells my App which controller/action should process the AJAX call.
The controller/action handles this request just fine. The action grabs the ID as a URL parameter, updates the relevant model object, and finally returns back a 200 to the JS AJAX caller.
This all works great! No issues -- nothing to troubleshoot here.
My question is: In the example above, is it appropriate to define a get route within routes.rb to process this AJAX request? Or, is that bad practice? Should I instead be defining a put, since conceptually that is what I'm doing in this workflow (i.e., I'm updating an existing object)? I'm worried that, while this all works perfectly, I'm breaking some fundamental MVC routing standards.
If you are updating a resource it will most likely be a PATCH update, which means you aren't completely replacing the resource but are just updating it (this is why PATCH is the default HTTP method for updates in Rails, instead of PUT).
So, yes, you are violating RESTful conventions by using GET to update a resource. GET is only used to fetch a representation of a resource...without changing it in any way.
When I submit a form, a number of parameters are set without showing up in the url.
I would like to do the same thing with link_to:
<%= link_to((purchase.paid ? 'yes' : 'no'), {action: :index, hidden_id: purchase.id}) %>
produces the url 'http://localhost:3000/purchases?hidden_id=1'. I would like to link to the url 'http://localhost:3000/purchases' while still setting params[:hidden_id] so I can access it in the controller, as if I had submitted a form.
My routes.rb file is as follows:
root to: 'products#index'
resources :products
resources :purchases
match ':controller/(:action/(:id))', controller: :shop, via: [:get,:post]
In answering this, is there anything I should know here about the difference in the way these two things are handled? Is it something about get vs post requests or is there some other principle involved which I'm not grasping?
Yes, it's to do with Get vs Post requests.
A Get request can only send parameters in the URL itself. A post request can also be sent to a URL that includes parameters in the URL itself, but it can also send parameters 'under the hood' so to speak.
So if your routes were set up to allow it, you could send either a get or a post request to http://localhost:3000/purchases?hidden_id=1, but only the post request could include additional parameters under the hood.
Anything else you should know about the difference in the way these two are handled? Yes. In most web frameworks, when you see the parameters server-side, they will be split up into GET params and POST params. Rails doesn't make this distinction, and puts them both in the same params hash. (I think this is silly, but whatever).
Also, a get request can be sent simply by entering the URL in your browser and hitting enter. A post request will generally only be executed by a user submitting a form on a web page. For this reason, get requests are not meant to change any content in your database. They should be for viewing information only. So, eg, if you have a button to delete a resource (eg. a blog post or something) it should be submitted via post. (more info on that at Why shouldn't data be modified on an HTTP GET request?)
Lastly, Rails provides an option in it's link_to helper to allow you to easily make the 'link' use a post request. See the method option at http://api.rubyonrails.org/classes/ActionView/Helpers/UrlHelper.html#method-i-link_to. This basically uses javascript to prevent the normal action of clicking the link (which would be a get request), and submit a post request instead.
In my Rails application I have an url routed to an action in charged of showing or creating (if not existing) e resource. What is the appropriate http verb to use for this kind of request?
To be more precise, in my method I don't directly access the resource but I use a library which has that behavior: first search and then create the resource if not exiting. My method, in the end, always provide the resource returned by the library either a brand new one or an old one. Hence I cannot split into two requests.
According to this and considering my method always returns the same resource (idempotent) it seems that PUT should be the right one. I just wonder whether PUT can be used in case where e resource is actually just retrieved (get) and anything is not even updated
tnx
POST for creating, GET for showing is automatically used by rails. But I hope you can do all sorts of things with custom programming as data will be available to you in form of params[]
According to Ruby on Rails guides, you should use GET and POST verbs. More information here: http://guides.rubyonrails.org/routing.html#crud-verbs-and-actions
You use GET to retrieve.
If resource found return 200 with resource.
If resource not found let it return 404 and check the error code and use POST and create the resource.
If you donot need any parameter while creating resource then you should use GET request Else if you need params while creating resource , then you should make separate action for creating(Post request with params) and showing(GET request) resource.
I am not understanding the difference between session and params in the following application.
A user submits a new movie form. How would the associated controller access the title of the movie?
session['title']
session.title
params['title']
params.title
All of the above
Based on the StackOverflow answer at Difference between session and params in Controller class:
params live in the url or in the post body of a form, so it vanishes as soon as the query is made.
Session persists between multiple requests (the info are often stored in cookies but this depends on your configuration).
To be short:
params: one request only (creation of one object, access to one particular page)
session: info to be persisted (cart, logged user..)
I chose (1) session ['title'] on the quiz and got the answer wrong. I chose (1) because I thought it involved accessing information that had to persist.
Am I misinterpreting the question and maybe this falls more under "one request only" so the answer should be (3) params['title']?
To attempt to answer your question in the context of this quiz instead of just in the context of code, consider where it says that:
params live in the url or in the post body of a form, so it vanishes
as soon as the query is made.
Now consider that the question itself says:
A user submits a new movie form. How would the associated controller
access the title of the movie?
So the question is saying that the user interacts by filling out a form which is then posted to the server. This is exactly the "post body of a form" mentioned in your notes.
So the correct answer is 3) params['title'].
Now, once this data is accessed, it CAN BE PLACED into the session, but that's for the developer to do or decide, and that's not really within the scope of what's being talked about here.
You also know that, in the context of this question, the session is not what's used because your question only refers to a single request: the sending of the form. If your question referred to data sent from the form that had to persist over a few more requests (such as a multi-page form), then the session might come into play.
Before access data you need to put it. In default rails generated forms all data is send in one request in params. If you have form that points to User#create action and have 'name' input, you will have params['name'] in User#create action.
Session is another thing. It's hard to find sessions in standart generated rails scaffold. You can access session as a hash. session['name'] will store name between requests. Read more
So, params are are generated for one request - to transfer data from user to server, sessions are used not for transfer data, but for store it.
The code generated in controllers for domain classes allowed POST method only for 'save', 'update' and 'delete'. Does this only because of that the GET method would show the params in the URL or it is out of other considerations? Like the semantic of GET is for obtaining while POST is for creating or updating?
I'm using Grails 2.1.1.
The consideration you mention is correct, when posting data you would not want to get that data into your URL. This could be cached etc. Another consideration is that more and more frameworks are following the REST principle in which is described what each HTTP method would be doing.
There is some more information over here:
Which HTTP methods match up to which CRUD methods?