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.
Related
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
Obviously, this question is a bit Rails beginner question, however it is vital for me.
I'm trying to get multiple variables (more than a single id, parameters like username,versionNo), nothing specific. What I'm trying to understand is, I'm writing the backend of an mobile application, when the client sends me JSON variables with post, in where I should try to serialize it, in order to use it for operations such as database querying. I'm assuming that it will be on controller, but still just want to be sure. Also within pre-defined 7 methods I've assumed that index method would be the most suitable function to do operations like database querying and etc.Since there are multiple parameters, I didn't think show operation would be feasible. But again there are tons of Rails experts in here.
According to CRUD, POST request should be equal to create method in your controller.
Read more here: http://guides.rubyonrails.org/routing.html#crud-verbs-and-actions
I have a system with a web UI that works as normal, and an API endpoint at /receiver_api. Users send emails which are parsed by Mailgun, who then submit a POST to this endpoint. There are a lot of possible actions that we may want to take, depending on the values of these params (create new post, create new reply, add subscription, delete subscription etc.), and when writing the handler it felt like we were doing a kind of routing again!
So we would like to choose the controller that we direct the request to based on what the POST params are. We are directing /receiver_api to a ReceiverApi#receiver controller/method at the moment, which inherits from ApplicationController. It currently effectively routes requests to other "fake" controllers that don't inherit from ApplicationController (since redirecting from one Rails controller to another wouldn't work). We would like to be ultimately routing to Rails controllers so we can use before_filter and all the other magic in them.
Anyway, one possibility that springs to mind is a method in routes.rb that accesses the POST params and returns the Rails controller/method that should be directed to. 2 questions:
Is this possible? Can you access POST params in routes.rb?
Is there a better way of doing this? We had thought about moving up a level into Rack, and will probably do this at some point, but would rather just get something out of the door if this will take a while.
Thanks!
Choosing a controller based on params is not a good thing to do.
A better alternative is to refactor your code (in those fake controllers) to methods in your model, and call model methods based on the params from your controller.
You cannot access params in your routes.rb, because it is run at initialization.
If you really want to call controllers based on params, there is a way of doing this, by redirecting to another controller. This is explained in http://www.railsonwave.com/2008/10/25/how-to-call-a-controller-s-action-from-a-different-controller/ [bad link], but do note that it is very much a hack.
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.
So I know that you shouldn't use UrlWriter methods in a model, but I wasn't sure what a better way to handle my current situation is.
Basically, I want to allow a User to post something to his facebook feed, and want to write a post_to_fb_feed(object) method in class User. Now, the URL of what is actually posted depends on the object, so I also have a to_fb_feed_item method on the object classes that a user can post. The to_fb_feed_item method just returns a hash that the Facebook API expects, including the url the post should link to.
I've gotten this to work currently, by including ActionController:UrlWriter in my models, but I was wondering if anybody had a better suggestion for how to handle this.
Thanks!
Eric
including ActionController:UrlWriter is the best way to handle it. I don't know why it's not easier to generate urls from arbitrary places in Rails -- sure it might be more common for the appropriate place to be in controllers and views, but the fact of the matter is many models validly deal with urls as data, and need to generate them.