API licensing

[puckparches]

As many website owners know, surviving solely on advertising revenue is no longer possible; Google is consuming all of our profits. For years, businesses have approached me to license the content of my website, but since I was doing well with advertising and lacked knowledge on the subject, I never pursued it. Now, with advertising revenue declining, I would like to start licensing the content. Currently, I have the content stored in an SQL database, and I use PHP on my pages to serve the information. Where do I start with creating an API to license the content? I only know basic PHP

[mack]

Knowing php will be extremely useful!
What I would do is provide the content to the consumer as a PHP file (discussed as an XML/RSS/Json file) whatever you are able to work with or have experience with.

I don't know your exact circumstance so here is a simplified version of serving content...

The user signs up with you and gets an API Key. xxxxxxxxxx then on their page they create a PHP file to request the content from you. For this example, we will request a list of articles and an individual article.

For the article list, they send a request example.com/feeds/latest.xml?key=xxxxxxxxxx

On your server you have a PHP file that receives this request... in this case, an XML file being parsed as PHP. You then extract the key=value from the URL and do a lookup to determine if the key is valid. You can also do another stage where it checks the referring IP to ensure it has come from the correct server. If the IP and key both match the customer then allow the file to be returned.

The third-party would then need to have a 2nd file set up to request and render the individual articles. This can be simple or complex depending on how the user wants to display them and how they want to structure the URLs. I guess that part is worthy of a discussion on its own..

The request for the content will again be made from a file on the client's server and will request the article along with the API Key that you have provided them with. It will then return the content as a file that can be parsed on the third party's server.

Effectively the third-party server makes a "get" request for the content and passes credentials as string values. Your server then verifies the details and if they are accepted returns the content.

I hope this gives you some ideas.

Mack.

[puckparches]

Hello Mack!

I apologize for the late response.

Thank you very much for your answer, it helped me to get an idea of how to do it. I got confused with all those API Platforms, API protocols, and more information. I didn't know where to start with all that, but, as you suggested, I could start with something simple.

[mack]

Keep it simple :-)

An API platform can be as simple or as complicated as you need it to be. PHP/MySQL will get you a functional back-end. For verifying the API credentials I would use a simple MySQL database with a table called apiusers. Within that table have something like id, username, password, domain.

You can then provide a user with access using a username and password. When a user submits a request to your server, you can extract the username and password. You will also get the domain passed as part of the request.

Select the credentials from the database and if there is a match then allow your server to respond with the returned feed.

Obviously, you don't want the user to send the username and password in the URL, this just makes it too simple for others to intercept it. It would be safer for them to include a file (within another PHP file) and use that file to call the request. Even this would not be entirely secure and it could be intercepted.

Curl is one way to achieve it and curl is often used for requesting syndicated content.

Mack.

[puckparches]

Thank you very much for your response.

Today, a second company requested access to my content. Hopefully, with this, I won't need AdSense anymore and can just sell my content through the API. I'll definitely suggest they use Curl to make a request.

[NickMNS]

The most commonly used / expected method for providing an API is using REST/(JSON). It essentially consists of providing an endpoint, that maps to the requested data. eg:

https://example.com/api/(product-name)/(size)

where the client makes a request

https://example.com/api/widget/large

and you then return json object with the specs for the widget size large. If the client wants data on gadget size small, they then make a request with those params.

Here is an article which explains it in more detail.
[stackoverflow.blog...]
The article use express.js for the server side, but you can easily find tutorials online for PHP.

As for security and user authentication, this is typically done using a system of keys/tokens, see: [jwt.io....]
implementing this can be complicated, and it can be also be done wrong, with little to no warning.
An easy (less secure) solution to start out would be to use a subdomain for each client, then limit access to the subdomain to single or few IP addresses that only the client uses.

Caveats:
Whatever you do you will need to rate limit what the client can access. Otherwise your client can in a very short time access all the data, store it, and then cancel the contract and then have access to your data forever more. Even if your client doesn't act nefariously, the additional requests on your system, if too frequent, could cause you problems.

[Kendo]

API sounds like overkill when all you really need is login based membership access, and that you can do simply with any one of the most popular CMS like WordPress, Drupal, Joomla and Moodle.

However if you want more than password control because passwords (and API) can be shared, try using a DRM solution that locks the user's unique computer signature to their account, thus preventing others from using the same account. For WordPress try the SafeGuard DRM plugin.

Another solution that provides DRM, but with the option of copy protection is a web hosting service known as Guest Video Protection. Their file hosting caters for any images, PDF and video embedded on the web page.