I am trying to gather data with api calls from fortinet devices. Currently I need to extract data from a FortiGate. I can't seem to find an API call that gather the data I need but I also don't find any other way to gather the data with API call. The data must be gathered with API not snmp of ssh.
The data I need from these firewalls are:
-Nat exhaustion (maybe a way to send exec commands to cli?)
-Hash of admin users
If you have suggestions please feel free to leave them here :)
Related
I primarily deal with REST json APIs at my work. So I am familiar with them. But for my own project I am trying out app engine as I believe it is a great fit.
I had already started writing my logic in python (using ferris), and in reading more on app engine I came across protorpc and cloud endpoints. But in most of the examples I have read, they seem to be doing the same just as I would do in a rest api. Make a request with json, and get a json response back. Or an error.
The main difference I see, is that in rest, the endpoints are based around a resource. And the HTTP verbs around them such as GET, POST, PUT, DELETE, etc. Where as in RPC, each request would have it's own endpoint rather than be based around a resource or model.
Both are requested with, and respond with json. So I think I am failing to see the benefit of using Google endpoints. Do they offer some other kind of benefit? I could maybe see better analytics tracking with endpoints. But wouldn't I still need to the use post http verb for modifying content?
Would any of this change if I was using certain frameworks? Like django. Although I am currently testing out Ferris which has a messaging system that deals with protorpc. Although, I have not been able to rest or yet.
So what am I missing? What are the benefits of endpoints over just making my object methods handle a json request. Do socket connections play into this at all?
You can do both by using endpoints to make a RESTful API.
protorpc/endpoints doesn't magically make your API RESTful. You have to make your API RESTful within the endpoints framework, which uses protorpc.
The benefits of using endpoints is that you can get a lot of the authentication work done easily (assuming you're going to use Google accounts), the serialization/deserialization is done for you, your client libraries can be generated for you, and more than just a Javascript client can be supported. If these things sound good, endpoints may be right for you. If these things don't apply, then maybe be more direct and use RequestHandlers yourself.
I was able to make a simple API using endpoints. It has 3 main resources: records, datasets and moves. A Record object is the smallest unit of data. The Dataset object is a group of records. And the Move object represents the event of a Dataset changing location.
My RESTful URIs look like this:
GET /records # Get list of records
GET /records/<id> # Get single record
POST /records # Create records
GET /datasets # Get list of datasets
GET /datasets/<id> # Get single dataset
POST /datasets # Create dataset
GET /moves # Get list of moves
GET /moves/<id> # Get single move
POST /moves # Create move
With this I can create data, organize it and move it around. I was able to do this completely within the endpoints framework on App Engine and it is RESTful.
Is it possible to use Mailchimp API to subscribe emails to the lists of MY USERS' Mailchimp Accounts and not my own?
Basically I have a web app, and users collect emails of various subscribers through this app. I then want them to be able to click a button and subscribe all those emails to their lists.
I've looked at Mailchimp's API - particularly the /lists/subscribe and the /lists/batch-subscribe methods. However so far it appears that these will only work for your own Mailchimp account and not for remote users' accounts.
Can someone please tell me whether what I'm trying to achieve is possible with Mailchimp's API?
You would need to execute the api-calls with your users' api-key, which would mean that you execute the calls with their credentials.
There are three different ways to get their api keys, with different practicality levels.
You guess. They look like guids without dashes, and some information about which datacenter it is associated with. Some easy (and somewhat bad) calculations indicate that there are 2^128 api keys in every datacenter, so this will consume both cpu- and network-resources, and invoke the rage of the Mailchimp. The linked image shows him on a good day. He won't be as pleasant if you choose this alternative. Dont do this.
You ask, in an evil way, for their username/password. This is bad since it will give you to all accounts those credentials works with. This would also give you access to stuff that aren't available using api calls (like payment stuff). This wont work at all if your user is intelligent administrators that are using AlterEgo, the two-factory security alternative. This alternative is less bad than blindly guessing, but still provides too much access, if it works at all.
You ask, in a user-friendly way (with perhaps some quick tutorials), for the user to generate an api-key in mailchimp to provide to you. This is the Good Alternative (tm).
You may choose any implementation as long as you choose number three.
I am trying to create a REST API for my web service.
I want to make the users of the API able to initiate a new request with my service. This involves uploading one or two zip files along with some other parameters.
How can I make this all combined into one request? Or is it better to do it multiple requests somehow?
I don't have a lot of familiarity with making REST APIs so I don't know how people usually do it.
I'm using PHP for my site if that matters.
To do this, you'd need your client to upload in mime/multipart format. I don't know PHP, but I'm sure there's a library out there that will support receiving/parsing the multipart messages you get.
As for whether it's a good idea .. If initiating the request is the creation of a single resource, it's not unreasonable to accept mime/multipart. If the parts being sent are themselves full-fledged resources, it would probably be better to make the client send them up separately, and reference them in the initiation request. Also note that mime/multipart is going to be a bit harder for your clients to deal with than simple requests.
This post seems to be related to what you're trying to accomplish.
Using Wufoo's API, is it possible (and if so how) to retrieve a single entry and update the information in it (without submitting it as another entry)? I can't seem to find any information on the Wufoo API website. If this isn't possible, any suggestions as to to work around this (such as using a local db). I'd like to build a hybrid app that authenticates locally and uses Wufoo for the data collection.
Thanks :)
I've been working on a similar kind of project and ran into the same issue. After submitting a help ticket, I was informed that the wufoo API does NOT support this function (update). Any updates would have to be done externally.
Like you, I would like to store my data in wufoo rather than externally, so I'm working on a few scripts that will serve as webhook endpoints for my wufoo forms. Whenever a form is submitted, one of these scripts will receive that data, do stuff with it, then use the API to relay the modified data back to a second wufoo form that "shadows" the original (same fields if needed, or new fields that reflect the processing I did).
This second set of forms would be the final destination for the data and only be accessed by my code. The first set of forms would only be accessed by live users. In a nutshell, it's a huge feedback loop that uses webhooks to trigger the processing.
Hope this helps.
for more info on webhooks, see http://help.wufoo.com/articles/en_US/SurveyMonkeyArticleType/Webhooks?q=webhook&fs=Search&pn=1
for more info on the wufoo api Entries api (get & post), see http://help.wufoo.com/articles/en_US/SurveyMonkeyArticleType/The-Entries-API
I have read the docs for SkyDrive REST APIs but didn't find any API using which i can sync with the SkyDrive, without recursive polling the folders for update check.
Is there any API to get only the update for a user Drive?
A commonplace reality of epistemology is that...
It is typically much easier to prove that something exists than to prove that it does not exist
Never the less I can say with a high level of confidence that the official REST API for Skydrive doesn't include a way of getting a list of updated documents for synchronization purposes.
Furthermore I didn't see any evidence of a non-supported/non-official API that would serve this purpose and by observing the way the Windows Client for SkyDrive interacts with the server (within limit of fair-use reverse engineering), it appears that the synchronization is done by reviewing the directory tree rather than getting a differential list.
I believe the closes you can go is: Get a list of the user's most recently used documents
To get a list of SkyDrive documents that the user has most recently
used, use the wl.skydrive scope to make a GET request to
/USER_ID/skydrive/recent_docs, where USER_ID is either me or the user
ID of the consenting user. Here's an example.
GET http://apis.live.net/v5.0/me/skydrive/recent_docs?access_token=ACCESS_TOKEN