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?
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.
Is it possible to replace the standard link_to structure :
link_to "France", :controller => :static_pages, :action => :france
BY referring not to a controller but to a helper's method or a concern's method
- link_to "France", :helper => :my_helper, :action => :method_name_inside_helper
- link_to "France", :concern_module => :country_concern_module, :action => :method_name_inside_the_concern_module
Why would I like to do that: Indeed using a controller forces me to create ONE route per country and use redirects...I'd rather just use a helper or a concern module that do do force me to create a route when using one of their method.
Thanks!
MVC
The answer to this is that since Rails is built on the MVC programming pattern, you have to adhere to certain "conventions which are present in this type of framework:
The bottom line here is that when you request a URL, what you're really doing is sending a request to Rails, which will then route the request to a particular controller action.
Helpers & concerns are there to provide extra functionality to the various controller actions that you serve.
To answer your question - you need to use your routes to send a
request to your controller, which will then be able to pull data
from your model, showing in your view
--
OOP
A further explanation of this will come from object-orientated programming, which Rails is very much built on.
Everything you do in Rails needs to revolve around objects. Each controller action, model call, view, link, etc, needs to involve objects. These allow you to create a system which advocates & facilitates the adaptation & manipulation of the various objects
Now, your question is whether you can "route directly to a helper method or concern". The answer here is "no", simply because that is not object orientated. It's method orientated
Ever wonder why Rails' routes are declared with resources?
It's because Rails entire system needs to be constructed around objects / resources. This means your controllers will be able to provide a central set of "CRUD" actions to support the manipulation of these objects for you
Short Ans: No, you can't.
Long Ans:
You can't point links or URLs directly to helper or concerns. These are modules, they can't handle requests.
You will need to point to contoller's action first. In the action, you can call helper/concern methods and return result after processing.
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.
Just curious, params are supposed to be hashes containing details regarding browser requests. But debug(params) returns
controller: controllername
action:actionname
.
.
.
Is there any specific reason it contains these key-value pairs?
params comes from three sources
The URL
The query string(GET)
The post data often by form submit(POST)
The controller name and action name comes from URL. Say the url is "article/123", Rails will know:
The controller is ArticlesController - Because "article" is the first part of url
The action is #show, because the request is GET and there is an ID
Any controller and action can be recognized once you have defined them in routes.rb. Remember you need to assign controller name and action for custom route?
I'm just speculating, but this might be from the days before Rails was built on Rack. Nowadays, you would just put these things into the Rack environment (and they are probably in there now). They are probably still there for backwards compatibility.
So you can query those in before/after/around filters, views (not the best practice), and methods shared between multiple controllers
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.