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).
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've come across two scenarios with regards to creating a REST API in Rails and I wonder which one is preferred. Usually
if you know that you're required to have a REST API for your application at start. Does it make sense to have it in a namespace and thereby duplicating the controller logic?
I've seen examples where people have an application already and later figure they need to extend and offer a REST API. The approach to this has been to create new routes with namespacein routes.rb and controllers/api/whatever.... This still yields duplicate code though, but might be more sensible approach. The difference being a stateless machine for the REST API calls.
Can anyone elaborate on the preferred approach, thanks.
If you create a Rails application, and following the usual conventions, you basically end up with a REST API. Unless you are talking about a more specific meaning of the term (which I am not aware of), "REST API" is more a bunch of general characteristics of the API (i.e., things like statelessness, resource-based URIs if using HTTP, etc.).
So to turn the question right back to you: which case are you thinking about where a (conventional) Rails application is not by extension trivially a REST API?
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.
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.
I am pondering on using a Restful implementation in Rails. I'm asking myself if it's the way to go.
Should I always go for a Restful implementation or not?
I think there really isn't much other option as far as Rails goes. You would just be fighting against all the design decisions and sensible defaults that Rails, as a framework, has already made for you.
Think about all the provided shortcuts for routing, pathing, forms, etc. I think you would end up just spending more time/effort on a non-RESTful implementation.
The first thing to sort out is what REST really means. Fundamentally it is about utilizing HTTP efficiently and correctly. That is, GET requests don't modify anything, PUT requests are idempotent, etc. The notion of uniquely identified resources just sort of falls out of this optimal usage of HTTP. The beauty of REST is that you gain the maximum programmatic benefit out of HTTP, making things like caching, proxying, and automatic retrying able to work fairly well without any knowledge of the application whatsoever. Dare Obasanjo wrote a nice rant on the topic of REST misunderstanding. This contrasts heavily to something like SOAP where you have an heavyweight envelope format that uses HTTP as nothing more than a glorified transport layer.
Now when it comes to Rails REST there is a whole nother thing going on, and that is Rails' convention over configuration. Rails REST is just a thin baked-in layer of tooling to make it easy to define CRUD operations on resources you define. Note that these resources don't need to correspond to ActiveRecord models, and certainly using Rails resource routing is not a pre-requisite for designing a RESTful application. What Rails gives you is an extremely handy default for dealing with things that fit the model of a CRUDable resource, however you shouldn't hesitate to define additional methods on top of resources, or to forego resources altogether if you have pages that don't really seem like resources (eg. reports).
The bottom line to keep in mind is that it's not one or the other. Rails RESTful helpers are using the same primitives that have always been in Rails. You can use both together and they jive nicely.