Is there any software I can install that will give me information about my API usage in Rails? I see some API management services but they are all VERY expensive and very complex. I want something to give me basic information about my API.
Also, log analysis seems a way to go. However, I'd like to know if this is the solution that is most used by companies right now. They must use something?
Thanks
if your users already have API key, you can track the activity by following code:
#applications_controller.rb (controller)
after_filter :track_api_usage
private
def track_api_usage
current_user.api_tracking(params) if params[:api_key]
end
#user.rb (model)
has_many :trackings
def api_tracking(params)
trackings.create(self.id, params)
end
Why not add an API key which users of your api need to register for, like google maps. Make it as easy as possible otherwise they wont use your api. Having a key for your API means you can prevent usage abuse of your API. I.e. if there is too much traffic from a registered address then you can cut them off.
Related
I'm trying to figure out a way to create orders via API (the ones that show up under https://app.goshippo.com/orders/), but seems like api docs dont really explain how to do so, and the only thing thats available is to create shipping labels. The libraries dont have any functions that will point me to this direction either. Is it even possible to make a call to the api for orders ?
Also, if this is not possible, how can I make goShippo send me a request for lets say a CSV, to sync all orders ?
PS: this is a custom build
Thanks
Feel free to use our order endpoint /v1/orders, but it is currently in beta version. The behavior of this endpoint may change (fields, error messages). We will update the following gist according to any modification that we make.
You can find more details about the endpoint at https://goshippo.com/docs/orders
The following Gist shows you how to POST on the Order endpoint.
https://gist.github.com/mnowik/59d2d550107b77cb31bf79b6b75d6e27
Fields with * are not active yet.
Here is an excerpt from an assignment I am currently doing:
Build a dummy app that:
Contains a REST API that operates over a single resource.
Contains a Backbone client that consumes that API and can list, show, create, update, and remove that resource.
My understanding was that the term "consume" implies total coverage of the API's exposed ressources. However, the assignment says "consumes that API and can [CRUD] that resource".
Is that sentence redundant or is my understanding of the term wrong?
(Bonus question: why searching Google for this question returns countless language-specific tutorials for "consuming an API" but none explain what the term actually means?).
To consume an API means to basically use any part of it from your application.
Consuming an API here means creating a client which can send requests to the API that you build.
It appears that you need to create and API which can handle Create, retrieve, update and delete (CRUD) of a resource. For instance if your REST api is to create a blog, your API should handle CRUD functions for the object/resource blogpost.
POST - Create a blog post
GET - Retrieve a blog post
PUT - Update a blog post
DELETE - Delete a blog post.
It is about the direction of the app's interaction with API - it either provides an API, or consumes it, so there are providers and consumers of API, and this is just a less general and ambiguous term than 'using'.
Simply consuming an API means using it in your application.
For, e.g., GET request to https://someapi/Users will give you all the users.
You need to request this URL https://someapi/Users to get all the users and then you can use it into your application.
I always think about Albert Einstein's quote of "If you can’t explain it to a six year old, you don’t understand it yourself." when someone asks a question that you might take for granted due to technical experience you have on a subject.
I think the following medium.com article does an excellent job explaining it: How do you explain API to a 5-year-old?
simply means : using the API.
You can do it with HTTP method (GET, POST, PUT, DELETE..) using something like Postman (Tool) or maybe you have a client app/library that calls these methods implicitly.
Question
How do we make a resource not a verb... but still maintain its special actions outside the default GET, POST, PUT, DELTE actions?
Details
I have been searching for some time now about the proper way to build a RESTful API. Tons of great information out there. Now I am actually trying to apply this to my website and have run into a few snags.
What our site does:
Our site site allows people to play games and win prizes.
The API will allow developers to build their own games and use our backend to collect, validate, store user information and give out prizes.
Scenario:
Developers will create their game then make a call to our API to let the player play the game (play_game). This play_game method combines multiple functions that we do not want a developer to run independently.
Here is what a play_game call does on the server:
It accepts player data the developer wants to store.
Validates the data (compares it to rules setup in the control panel)
Calculate what prize should be given.
Returns what prize was won to the Developer.
In addition there are multiple functions behind the scenes that get triggered like sending emails, etc.
Resource This is what our current resource looks like:
http://site.com/api/play_game
Issue:
This doesn't hold to the idea of no verbs in RESTful API's.
How do we make this resource not a verb... but still maintain its special actions outside the default GET, POST, PUT, DELTE actions?
Notes:
After asking this question I have decided to use Phil Sturgeons RESTful Framework... unless someone has a better idea.
You could place the following code into applications/routes.php
$route['(.*)'] = 'api';
Then you could access your API like:
http://site.com/play_game
BUT
You'll only have access to ONE controller only (your api controller)
Hope it helps
I would like to be able to generate custom bit.lys (http://bit.ly/thecakeisalie type things) through their API. This does not appear to be possible, but I thought I'd check; does anyone happen to know otherwise?
This unfortunately had to be removed for our free users due to on-going abuse. All of the custom bitlinks on bit.ly are created in the same key space, so allowing for automated creation there quickly leads to there being no sane options availble for anybody else.
That being said, we have recently added the ability for our paid customers to create custom bitlinks if they are using a custom domain. In this case, our customers get their own key space so creating custom bitlinks en-mass isn't a problem.
It was removed from the API. I like many others were trying to do this and bit.ly's support email replied saying it has been removed. Similar experiences on their ApiDocumentation wiki here.
I'm a new REST convert and I'm trying to design my first RESTful (hopefully) api and here is my question about addressing resources
Some notes first:
The data described here are 3d render
jobs
A user (graphics company) has multiple projects.
A project has multiple render jobs.
A render job has multiple frames.
There is a hierarchy enforced in the data (1 render job
belongs to one project, to one user)
How's this for naming my resourses...?
https:/api.myrenderjobsite.com/
/users/graphicscompany/projects
/users/graphicscompany/projects/112233
/users/graphicscompany/projects/112233/renders/
/users/graphicscompany/projects/112233/renders/889900
/users/graphicscompany/projects/112233/renders/889900/frames/0004
OR a shortened address for renders?
/users/graphicscompany/renders/889900
/users/graphicscompany/renders/889900/frames/0004
OR should I shorten (even more) the address if possible, omitting the user when not needed...?
/projects/112233/
/renders/889900/
/renders/889900/frames/0004
THANK YOU!
Instead of thinking about your api in terms of URLs, try thinking of it more like pages and links
between those pages.
Consider the following:
Will it be reasonable to create a resource for users? Do you have 10, 20 or 50 users? Or do you have 10,000 users? If it is the latter then obviously creating a single resource that represents all users is probably not going too work to well when you do a GET on it.
Is the list of Users a reasonable root url? i.e. The entry point into your service. Should the list of projects that belong to a GraphicsCompany be a separate resource, or should it just be embedded into the Graphics Company resource? You can ask the same question of each of the 1-to-many relationships that exist. Even if you do decide to merge the list of projects into the GraphicsCompany resource, you may still want a distinct resource to exist simple for the purpose of being able to POST to it in order to create a new project for that company.
Using this approach you should be able get a good idea of most of the resources in your API and how they are connected without having to worry about what your URLs look like. In fact if you do the design right, then any client application you right will not need to know anything about the URLs that you create. The only part of the system that cares what the URL looks like is your server, so that it can dispatch the request to the right controller.
The other significant question you need to ask yourself is what media type are you going to use for these resources. How many different clients will need to access these resources? Are you writing the clients, or is someone else? Should you attempt to reuse an existing standard like XHTML and classes/microformats? Could you squeeze most of the information into Atom? Maybe Atom with some extra namespaces like GDATA does it? Or is this only going to be used internally so you can just create your own media types, like application/vnd.YourCompany.Project+xml, application/vnd.YourCompany.Render+xml, etc.
There are many things to think about when designing a REST api, don't get hung up on what your URLs look like and you should really try to avoid doing "design by URL".
Presuming that you authenticate to the service, I would use the 1st option, but remove the user, particularly if the user is the currently logged in user.
If user actually represents something else (like client), I would include it, but not if it simply designates the currently logged in user. Agree with StaxMan, though, don't worry too much about squeezing the paths, as readability is key in RESTful APIs.
Personally I would not try to squeeze path too much, that is, some amount of redundant information is helpful both to quickly see what resource is, and for future expansion.
Generally users won't be typing paths anyway, so verbosity is not all that bad.