When an application is moved to the Web, the process also involves transitioning the application programming interface (API) along with it. However, there had been a downside until recently. Traditionally, APIs were built around a remote procedure call (RPC) in order to make these interfaces look and feel like functions. As Hypertext Transfer Protocol (HTTP) is normally connectionless, the RPC made it strenuous to move APIs to the Web. In simpler words, it was hard for a third-party application to fetch data from the API of a parent application.
The introduction of Representational State Transfer (REST), a software architectural style, has made it a lot easier to GET (which means, retrieving a data on the Web) an API data from an iOS app, an IoT device, and even a client-side Web project. As RESTful APIs are independent and not tied to the client-side technology, they help develop large and scalable applications for long-term usage.
STEPS TO WRITE RESTFUL APIS IN PHP
A simple RESTful API in PHP consists of two classes: the Abstract class that handles the parsing of the uniform resource identifier (URI) and returning of the response, and the Concrete class that consists of the endpoints of the API. Before writing either of these classes, however, a third component requires special attention – an .htaccess file. Writing this file helps in configuring a central script that processes every request sent to the RESTful API.
Once the work on .htaccess file is complete, you can start writing the Abstract class. Acting as the wrapper for the API endpoints, this Abstract class will be able to take requests, detect the used HTTP methods (GET, PUT, POST, and DELETE), and assemble data from the URI. After declaring the class and its properties, complete the class by writing an array map of all the possible HTTP codes based on your specific requirements.
While the Abstract class looks after functionality, the Concrete class comes into the picture to introduce an enhanced security system. By closing down the vulnerabilities, unique domain names and secured API Keys will allow only the authorized external hosts to connect to the API service. In most cases, writing the Concrete class also requires to define a unique token that verifies the request of every user.
MITIGATING THE CHALLENGE
Writing RESTful APIs seems simple, isn’t it? Yes, it undoubtedly is! However, this doesn’t mean you won’t be facing a little challenge on the way.
Customizing and Testing
As the default installation may not work for everyone, you should consider a bit of debugging from the development end. In short, you need to do some code tweaking while using pre-packaged REST API PHP codebase. While this customization itself can take a substantial amount of time, the biggest challenge with writing RESTful APIs is its testing procedure. The test-runs can be lengthy, depending on the level of customization you’re doing to the pre-packaged codebase. If the test runs show errors, fixing them can also increase the amount of time taken to complete the API.
As a pro tip, we suggest you visit Stack Overflow, a Q&A site for programmers, in case you’re stuck with an error during the tests and become unsure about your next step.
Security is a very important part that one has to keep in mind while dealing with data. In making RESTful API a secured one, there is a need to implement oAuth Authentication (to be more specific oAuth2). In oAuth, one has to deal with ‘user key’ and ‘secret pair’ instead of sensitive user-data (say username and password). This means that while signing up with an app, the system can just hand over the user a key-secret pair (termed as consumer-key and consumer-secret) and the entire authentication process can then work on the basis of this key-secret pair.
oAuth authentication can be categorized as 2-legged authentication and 3-legged authentication. Without digging too much into the technical complexities, the steps behind this process can be simplified as follows:
Step 1: User requests the access to an app by showing his or her key-secret pair
Step 2: Authentication server then validates those keys, and if validated, it responds with an access-token
Step 3: Only the user can access the resource (through API call) using that particular access-token for that particular session. By the term ‘particular session’, we mean that one cannot access the resource server using the access token again and again; users have to collect the access token for each call.
A sample code excerpt that describes these above-mentioned steps can be presented as below:
// get a request token
$tokenResultParams = OAuthRequester::requestRequestToken($options[‘consumer_key’], $id);
// get an access token
OAuthRequester::requestAccessToken($options[‘consumer_key’], $tokenResultParams[‘oauth_token’], $id, ‘POST’, $_GET);
$request = new OAuthRequester($API_URL, ‘GET’, $tokenResultParams);
$result = $request->doRequest($id);
With oAuth authentication, one does not have to deal with his/her account sensitive data such as username and password, while making an API call. This means that changing or updating one’s password etc does not at all affect the whole authentication process, while keeping the security as tight as possible.
So if you’re aware of the basics, writing RESTful APIs is not a cumbersome task. And believe us when we say it, you’ll be reaping a lot of benefits from it in future.
Yearning to know more about RESTful APIs? Contact us here.