This is more or less an idea I had a couple weeks ago, and the more I think about it, the more it makes sense. The idea is to separate API's into 3 groups:
Internal; and separate out permissions and security dependent upon each group.
As far as I am aware, there is no standard out there similar to this. If you do know of one, please enlighten me.
Application Public Interface
Now not to confuse anyone, the "Public" in API is a reference to how the interface is accessible, whereas these terms would reflect the group of people who should be accessing the interface, as follows:
- Public: Meant for anyone to see
- Semi-Public: Visible/accessible only to members, partners and/or affiliates.
- Internal: Only visible/accessible to employees/members of your company/group/project.
This group of interfaces would show any information that might be available on your site, without logging in; of course, how much and what information is actually available through the interface is up to you. Depending upon your servers, and what information is available, you may want to limit how many requests an IP can make within a time-frame; but this is not required.
This group of interfaces would show information that is only available to those whom login, and may even allow modification of information. This group should not contain any information available in the "Public Group," and should limit the requests per login information, for a time-frame. This group would be required to submit a username and hashed password.
This group of interfaces would only allow the changing of variables and reflect little or no information. The idea here is to simply allow the remote management of a server. Statistics and tracking information for servers should be passed through a semi-public interface, not this interface. In addition to a request limit and username & password, it's recommended that you require a captcha response as well.
The recommend response for this interface is a simple boolean statement (e.g. TRUE/FALSE or 1/0), suggesting whether the changes were applied.
Finally, this group should only exist on a private server, or only be accessible under certain sub-domains and/or ports. In the case of a private server, the private server would act as a proxy for modifying other servers, while the other servers would essentially only accept modification requests from the private server's IP address. Otherwise using an alternate port or sub-domain would be effective as well.
I think that this could be a very effective system, and could work well for many. In any case, I think I will be further researching the subject, and even do some testing to make a real and practical system.