API Simplified?
 

This may sound stupid, but I have been going round and around attempting to get some one to explain API to me in terms that a coonass like myself can understand, I had one friend say it was as if a site mirrored your site with their performers working on your site and theirs at the same time. How does payouts work? Do i get their entertainer's information for my 18 U.S.C. 2257 compliance?

1. There are different types of APIs. API stands for Application Program Interface. In general terms an API is any program that allows your program to interact with it usually using a set of predefined functions. From your question I assume you are talking about the various Cam APIs that people are working with. Most of the Cam APIs are more properly called feeds although there are certainly some that are APIs.

2. The Cam Feeds that most people use provide a list of performers that are on line and various pieces of information about those performers such as age, gender, location, chat room url, etc. Using these feeds a third party (you) can build a dynamic site that displays these performers as if they are on your site. So while the information is indeed a mirror of what is on the main site, the presentation is not necessarily a mirror.

3. Payouts work out however the particular sponsor details them in their terms. In the case of Chaturbate you get paid twice a month about a week after the term ends so you get paid for the 1st through the 15th around the 21st or 22nd (usually, can be later) and you get paid for the 16th through the end of the month around the 7th of the month. In the case of Chaturbate my payments have been like clockwork throughout. Each sponsor will offer various types of payments. Could be by check, by payoneer or paxum, wire transfer, whatever they define.

4. On 2257 I use the original sponsor's 2257 page as the 2257 information for any particular performer. The chatrooms are hosted on the sponsor's sites and the images are pulled from the sponsors cdn so it is the sponsor that is hosting those pieces.

Hope that helps.

.

thanks for the input, i'm probably gonna whitelabel for the time being, until i can get some of the issues worked out with my own site...

Cam XML feeds are not APIs.

XML feeds are raw data output organized in <nodes>.

Perhaps, what you develop as a program to parse and manipulate that XML feed might be called YOUR API to the raw data of that XML feed.

The problem with XML (or RSS) feeds are that they are duplicate content. What is duplicate data in that feed, exactly the same as every affiliate gets, needs to be word substituted -- then used in the text. Or, that feed's data should constitute no more that 30% or 40% of that page(s) total textural content. That is, if you are looking to build SEO traffic by building dynamic pages utilizing feeds.

Mirroring is making a copy of a site. But nowadays a site typically has what is called a backend in addition to the public facing side that exposes HTML, Javascript, CSS, images, and movies that the user can download through their browser. Nobody can see the backend except the people working on it (programmers and business employees who have access to it). The backend dynamically spits out HTML to the browser and that is what can be mirrored. There's no way to copy a dynamic site entirely because it is not exposed. You can think of it like this. You can photocopy a painting but that doesn't mean you now have the ability to create other works of art in the style of that artist. It's not something that can be copied (only imitated). You can copy the painting because it has been exposed to the world, but you can't copy his brain so that you can create other variations. The public facing site that people see in their browser is the output, but there's a whole bunch of stuff going on behind the scene that generates that output that nobody can see.

Now sometimes, businesses want other people to be able to call upon the dynamic parts for their own purposes. Ex: a travel site that contacts a bunch of airlines and hotels to get data about deals on certain days at certain places with specific criteria. To do this a business will expose an API.

An API is allows one site (or mobile app, or whatever) to talk to another. For flights you might have something that looks like.

http://www.awesomeflights.com/api/findFlights?departing=LAX&arriving=SFO&startDate=2 016-06-15

In which case the server might respond with something like:

flights: [
{depart: 'LAX', arrive: 'SFO', flightNumber: '1234', departTime: '8:57 AM', airline: 'Southwest', price: 123.45},
... more flight options
]

And then awesomeflights could take that to spit out a list that the user sees in their browser.

Businesses generally expose APIs to other companies so that they can get more business. In the example of airlines, it's a pain in the ass for someone to go to each different airline individually and see what flights are available. They want to go to just one place. So someone who comes along and says, hey, I have an idea of how I can improve upon your business, can simply access their API and create their own site that has the same functionality.

APIs effectively exposes a part of the backend that the business wants to make available to others.

Another example would be a County Clerk Office that gives you access to information. You go there and say I want information on XYZ, or I want to make a payment for XYZ, or whatever. Those are all services and transactions that a person could perform. The API would be the automated means of doing that so a computer could do it. And then other people can build their own value added services and businesses that build on top of those data / functionality.