What are the cons in using the generic route:
match ':controller(/:action(/:id(.:format)))'
I was told it is not recommended yet I do not see why. What problems can I get from using this?
Because it's easier to implement REST if you use the opposite ordering, ':controller(/:id(/:action))', and rails now has more convenient ways to get the proper HTTP verb using explicit resource routes.
Understanding the basic principles of REST will make it easier for you to expose an API, should you choose to go down that route, which embraces the principles of HTTP. It also tends to keep you from doing certain unclever things, like making it possible to delete records using a GET request. (The uncleverness might not be discovered until Google or your internal search bot decides to index all the links to :delete actions.)
The basic idea is that a GET /Url should imply fetching a resource. When you put the action first, the resource is semi-obscured, and you're accidentally opening the door to potential errors because all of the HTTP methods can be used to call destructive actions. Using an HTTP verb-centric approach, you can send an UPDATE request to the same URL as the SHOW request.
A specific answer to your question, which I understand to be understanding cons of the generic approach:
One significant risk is that you make every single controller action (non-protected) available to your users. It gives them the ability to access your entire 'tree' of controller actions, which may or may not be desirable depending on your situation.
In addition, you give users the ability to GET rather than POST, POST rather than GET, etc.
The comment above it that is generated explains it pretty nicely.
# Note: This route will make all actions in every controller accessible via GET requests.
This means that you could theoretically do a GET request on a route that is only supposed to be accessible via POST. ie. You could do add a route called /postable to a user object, which should only be POST'd to, but if you use the rule above you can also do a GET request on it (with empty parameters).
You don't really get problems, per se. Instead, you lose out on the advantages you gain from using resource routing:
A common pattern that helps simplify controller design
Free RESTlike handling of HTTP verbs (GET, PUT, POST, DELETE)
Peace, Love and Happiness*
You can find out more about resource routing by reading the Rails Routing Guide.
* Peace, Love and Happiness not available in all areas. Terms and conditions apply.
Related
While easy enough to find technical, technology-dependent descriptions of URL routing, it's surprisingly difficult to find a coherent summary of the various use cases (situations in which it might be required). I need to know under what hypothetical circumstances I am likely to need routing.
Some of those deriving from dynamic URL usage are outlined here, but it seems unlikely that this list is exhaustive.
I'd be glad if someone could list these separately for static and dynamic URLs -including, where applicable, any more or less imposed by external tools and services.
If you find yourself talking in terms of HTTP actions such as GET, POST, PATCH, PUT, DELETE or equivalents, to my mind you're already going too deep.
As far as I can make out, this question was too stupid to be asked by anyone else. :-)
Tks..
Yes you do need routing, routing can be an excellent way to get users to be able to effectively share a resource and find direct routes to it.
URL routes are basically GET requests sent by the browser to the web application, so theoretically you can do just as well with POST requests (i.e. without URLs), however for the reason mentioned above and also as a best practice (supported by most modern web frameworks) it's best that you use proper URLs, POST requests are probably just fine too - but i would suggest to use them when obfuscation of some parts of the web resources from the end user is required.
I am doing the CodeSchool course on Rails API's and they often mention the word 'endpoint' but never define it. Can someone give a clear and concise definition of it and provide an example of a request reaching an end point in the context of Rails?
An endpoint, as I imagine they may be using it in this course, is simply a route defined by your rails application. In terms of an API (which can mean many things and is worth further research on your part), hitting that endpoint will serve up a resource from your application, or perform some form of action. An example may explain this better..
Say we have an application that handles users and we want our API to expose the users resource. If we follow RESTful convention for our API we will expose seven distinct 'endpoints' linked to seven distinct 'actions' (index, show, create, update, destroy, new, edit) surrounding users.
When building our API, we would make is so anyone who visits "www.myapp.com/users" via a get request is returned some data representation of all users in our application. "/users" is the endpoint. Likewise performing a post action to "/users" with valid data is how we create new users. "/users" is still the endpoint but under different context. If you wanted data for just a single user, it may look something like "www.myapp.com/users/1" in which case "/users/1" is the endpoint.
It is important to keep in mind that this example merely follows convention and is not an end all be all.
I would check out the Rails guide on routing if you want more information - http://guides.rubyonrails.org/routing.html
Resource https://edgeguides.rubyonrails.org/api_app.html they meant providing a programmatically accessible API alongside their web application
The default route file has the following segment:
# This is a legacy wild controller route that's not recommended for RESTful applications.
# Note: This route will make all actions in every controller accessible via GET requests.
# match ':controller(/:action(/:id))(.:format)'
So what exactly is the problem with letting Rails assume the controller, action, and view to display when the format is ':controller(/:action(/:id))(.:format)' ? I mean, for more specific things like nesting I can always use specific routes...
It's just a common-sense security measure.
It forces the designer to whitelist GET requests so that the app does not inadvertently divulge the contents of a table or record to a malicious user.
If developers are allowed to being lazy, they will be. We are super great at optimizing efforts.
Not being explicit about routes may help you save 5 seconds each time you have a new controller, but it will be a headache for new developers, which will be unfamiliar with your codebase and hence don't know how things are glued. They will have to reverse engineer your views-controllers.
Being there. Not pretty.
Being explicit is usually better.
Because not everyone is building the next Facebook and some of us do this for fun or to make simple apps that we use only on our development device or to simply not be a ass and "answer" a question with that actually has an answer, instead of make ourselves look uber smart and important:
match '/:controller(/:action(/:id))(.:format)', to: "#{:controller}#{:action}", via: [:get, :post]
I've been reading up on REST lately and it's become seemingly clear that verbs do not belong in URIs. If this is the case, is the standard "resource/1/edit/" that particularly shows up in Rails a violation of REST? And if so, what alternatives are there?
Don't confuse CRUD with REST.
Rails provides "Resourceful Routing", and the actions within the URL simply provide a resourceful interface. The HTTP request verbiage still remains RESTful, which is what counts.
Here is an insightful article which does a fairly good job explaining REST/CRUD (specifically in Rails).
in order to better understand how RESTful works in Rails and thus become better at producing such code, i would like to manually create a resource from scratch. I generally know how to setup routes, controllers and the likes, but i would be interested in checking out some tutorial(s) that describe just that in detail.
Do you happen to know of anything ?
I would first advise you to get your REST concepts cleared. In my opinion, REST is fairly misunderstood concept in the community. I would recommend understanding it first without sticking to rails or any other technology for that matter. Ryan Tomayko has written a killer blog post about it. You also might want to read Roy Fielding's paper, if you are into it.
Once you understand the concept clearly, implementing it in a technology is not so hard. For rails, create a blank controller and start adding the actions one by one based on your understanding of REST. Think about exactly are you doing in the action. Are you fetching the data and showing it to the user? In that case, you need to make sure that the action can only be called with a HTTP GET verb. Are you updating a record in that action? You probably should only be accepting a HTTP PUT verb for that action and so on... Here are some resources found on some quick googling which look good to me.
http://blogs.sitepoint.com/2008/02/04/restful-rails-part-i/
http://s3.amazonaws.com/ozonesoft.net_public/RESTfulRails.pdf
I would recommend reading the standard documentation of routes in rails. I think that's enough. But to understand what makes an app a RESTful app and what doesn't is the key.