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
Related
Hi I am using SHOPIFY api to create customer information, but there is no chance to pass parameters in this URL, so my question is that is it possible, by using POST methods can we create it?
The ShopifyAPI documentation shows that it is a RESTful API. Therefore when you make calls to it, you use the appropriate verb(s). In the case of creating a resource, such as a customer, you use the POST verb.
A POST verb can include parameters, so your question is unclear. You do understand basic HTTP of course? If not, the Internet has many thousands of handy resources that clearly explain the HTTP verbs of interest.
I have created a rails app that periodically pings list of urls stored in a Server table. Now I want to create an API so that another application can insert records into the server table using this API. I researched about this topic on the internet to death and could not find a solution. Can someone suggest me how I can use grape gem to create this API? Any relevant blog articles would be helpful as well.
The Grape framework is an alternative to the Ruby on Rails framework, not something you add on top. Since you already have a Ruby on Rails app, you can do this more easily by adding this feature to your existing Rails app, which already has the ActiveRecord models and database connection set up.
The simplest way to do it would be to create a controller action add_url and make sure there is a route set up to it. Inside the action, run something like this:
url = params[:url] # get URL from HTTP params sent with the request
Server.create(url: url) # add row containing the URL to the Server table
Then tell users of your API to send a POST HTTP request to the URL that routes to the add_url action, and set the url parameter of that request to the URL to add the list.
Even better than having an add_url action inside some random controller would be naming the action create and putting it within a controller like ServerController that handles the creation, showing, updating, and deletion of URLs to visit. This would follow the REST convention of organizing APIs, which is more familiar to API users and which gives you a guiding principle to help you organize. However, if you already have a create method inside your ServerController that presents a web interface, you will have to make the action more complicated by using Rails’ respond_to feature to determine whether you should show a web page or respond to an API call.
Note that the above code has no security features restricting who can add URLs, so depending on your purposes may want to add that feature somehow.
I have a decent amount of experience with rails, but I've always been a bit ad hoc with my development methods. I'm curious about how to be properly RESTful in rails. Here's an example of an app I'm working on now:
I have a few models, including a User, Pack, and Product model. The models each have a controller associated with them. If I want to create a new page called 'Dashboard', on which the User can create new records on the Pack model, as well as see their account information, how do I do this in a restful way? Do I create a new controller called Dashboard? Or do I add it to a controller that defines my 'Static Pages'? What's the best practice regarding pages that aren't exclusive to the actions on one model?
Thank you in advance!
Yes, basically you want one controller per resource. In this case the resource is a combination of things but since you've identified a singular meta-resource (a "dashboard") it makes sense. So, I'd create a DashboardsController and then have a route like:
resource :dashboard, only: :show
Then you can use dashboard_url for links to the dashboard.
NOTES: The singular resource in the routes file is important because it indicates you don't have a list of resources, just a single one. This means there won't be an index action and the show action will be the default -- thus dashboard_url doesn't require a resource to show to be passed to it. And, regardless, controllers are named in the plural -- thus DashboardsController.
I would create a DashboardsController despite not having Dashboard model. Then to maintain REST principles have a controller method :new and controller method :create. Simply disply the information on the dashboards/new.html.erb but have the form post to the :create controller action.
To supplement the answers already given, REST really exists to make an easily-consumable API. (Notably, Roy Fielding's work is in the area of APIs, and REST is built on top of HTTP methods that HTML doesn't allow.)
This has been a common stumbling block since RESTful routing debuted in Rails; people get the impression that every controller now needs to be RESTful and that the front end and API should never diverge. Frequently, though, the front end and API have different needs.
For resources you want to be accessible via an API—Products, Users, Packs—trying to be RESTful is ideal. For those sorts of uses, pdobb's advice to have one controller per resource is generally exactly what you're looking for. They make sense in the context of an API being consumed by a machine.
But what about the dashboard? Dashboards are generally an HTML view intended to be rendered in a browser and viewed by a human being.
Does a "dashboard" resource make sense in the context of an API? Would it make more sense to instead make that data available in other resources? Is that data available in other resources?
Even if a "meta-resource" aggregating data still makes sense, would it be more logical if the API version had another name, like AccountSummary?
I have a rather unique question that probably has a simple answer but I haven't been able to figure it out.
I am using rails 4.1 and creating an app that I want to accept urls that don't exist as part of a NFC tag registration process.
For example, let's say the app is located at example.com and I programmed an NFC tag with the url example.com/xyz123.
I don't want the rails app to spit out a 404 error but rather attribute that tag to the signed in User account and allow them to register that url to one of that users' personalized pages that they created.
I've dug into the docs on error handling but that doesn't seem to solve the problem and I can't seem to find where in the core API these requests are handled and how I might override them in the application.rb controller.
this is rather simple. just create a catch-all route
get '*path', to: 'tags#new'
the requested part will be params[:path]
i would recommend not having unscoped catch-all routes through. it's slow and a pita if you ever want to change your URL structure (you will want to do that at some point). always use some namespace www.some-url.com/t/xyz123
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.