Posts from ‘Programming’
When thinking of an API consider your self the MySQL database holding the information, and the client/user is the PHP file that renders that information, now to make it even more complicated remember you can’t really communicate with the PHP coders, furthermore you also don’t have a clue what they are doing with your data, or how they are doing it. You have probably just realized how hard this simple API is going to be when it comes to maintenance.
I point this out because it’s one of the most important concepts of deploying an API, you need to make something that will be scalable to allow new features to be deployed while in a way that will not break scripts using your old API methods. Once you release a feature on an API it is almost impossible to ever remove that feature again without really hindering coders, this is one of the biggest reasons for API’s been so simple, slowly developed and having fairly limited functionality.
These are a godsend for coders interfacing with an API, there is nothing worse than calling an API script and getting back “error” or a “NULL” entry. Having a status code database helps people understand whats actually going on, off the top of my head a few I would consider including are [Ok, Depreciated, API Limit Reached, Server Busy, Server Error, Invalid XZY variable, Integer Expected for XYZ, Premium Feature], this is not an exhaustive list.
There isn’t really much point in creating something if you don’t document it so people can under stand how to use it. Documentation is very important and should be written in a way that makes it easy to understand and clearly defines the functionality and limitations of the API. Probably one of the best things that you can actually put in here is sample code, another good thing about sample code is you can see how easy the API actually is to use for the client.
The easiest way to make a PHP API scalable is to expose the clients to functions that they can call by name, for example you might use the $_GET[‘method’] to allow the user to specify the function “getPortByNumber” (this is what I do for whatportis). Now in the api.php file I have a function called exactly that, so all I need to do is check the function exist and then run it using $_GET[‘method’]();
Now the function is very simple, and basically just runs my standard class Port::Get_Port_By_Number($Port), then just JSON_Encodes this into a valid JSON output, it’s also secure as the Port class has loads of validation in it to protect the HTML interface. However there is a massive security flaw here as I also have a function called “DeleteUser”, so with a bit of common guessing by a potential hacker and they could destroy my website. Don’t forget when creating an API that your actually introducing a whole new array of entire points for hackers.
Google can get lost or confused when browsing your website, a perfect example of this is my website www.whatportis.com there is really only a few pages that make up the whole site. However there is actually quite a lot of content and information in the database that Google could do with indexing, unfortunately you have to type a parameter such as “80” to see this information.
Sitemaps as the name suggests is just a Map to your website, basically your creating a sitemap.xml that will give the search engine a list of places it should look when trying to index your content.
As my website is built in php it made sense to use this to create the sitemap, so I created a file called “sitemap.php”. However search engines look for sitemaps that are called “sitemap.xml” as you output them in XML.
A simple work around for this is using a .htaccess file to rewrite your .php URL to a .xml URL, here is what I used:
Options +FollowSymlinks RewriteEngine On RewriteRule (.*)\.xml(.*) $1.php$2 [nocase]