Data-API

A desktop application is different than other applications, in that the API calls are made directly from the computer of a third party (which, most often, is the user). It doesn't matter in this context if the application actually has a UI/desktop component. The thing that is important is that the consumer key and consumer secret can not be expected to be only known by the API partner and the Service Provider (Hyves), nor is it possible to restrict the API calls to a trusted set of IP addresses.

The oAuth community acknowledges that there is no solution for this problem within oAuth, and generally it's accepted that this problem cannot be resolved without a trusted third party, or access to, for instance, a TCM (although obfuscation can do a good job of delaying the key and secret to become public). Therefore, the Hyves API deals differently with traditional server application API calls, and desktop application API calls.

The normal server API calls have a single set of oAuth consumer keys and secrets. Calls made with these keys are limited to a set number of IP addresses, there is a single rate limit to which all calls are counted; if that limit is exceeded, no more calls are accepted from any ip address.

For consumers flagged as Desktop Application Consumers things are a little different. You will receive two sets of keys and secrets. One set is for server API calls (and has the same restrictions as mentioned above), one set is to be used in the Desktop Application. This latter set of keys has no IP restrictions, and the rate limiting will be per IP address. This means that calls made to the API only count towards the limit for that single IP, if the limit is exceeded, no more calls are accepted from that IP address. This has no influence on the acceptance of calls from other IP addresses. The Desktop Application key/secret pair is restricted in which methods it can call. It can call all methods, except for administrative methods; this are methods that allow consumers to set or update global settings for their consumer key. You can check the method list to see which methods are administrative methods. The other key/secret pair can be used for these methods.

When create a Desktop Application Consumer, it's still important to supply IP ranges from which you want to make your administrative method calls.

In general, Desktop Application Consumers will have a lower rate limit, since a server will charge all calls to a single limit, where a desktop application will only change the calls of a single (or a couple of at most, running on the same IP) instances to the limit. Therefor it's recommended to create a Web Application Consumer for developing, since developing is mostly done from 1 ip-address so you will have a higher limit.