API stands for Application Programming Interface. At some point or another, most large companies have built APIs for their customers, or for internal use.

But how do you explain API in plain English? And is there a broader meaning than the one used in development and business? First, let’s pull back and look at how the web itself works.

<img width=

WWW and remote servers

When I think about the Web, I imagine a large network of connected servers.

Every page on the internet is stored somewhere on a remote server. A remote server is not so mystical after all — it’s just a part of a remotely located computer that is optimized to process requests.

To put things in perspective, you can spin up a server on your laptop capable of serving an entire website to the Web (in fact, a local server is what engineers use to develop websites before releasing them to the public).

When you type www.facebook.com into your browser, a request goes out to Facebook’s remote server. Once your browser receives the response, it interprets the code and displays the page.

To the browser, also known as the client, Facebook’s server is an API. This means that every time you visit a page on the Web, you interact with some remote server’s API.

An API isn’t the same as the remote server — rather it is the part of the server that receives requests and sends responses.

APIs as a way to serve your customers

You’ve probably heard of companies packaging APIs as products. For example, Weather Underground sells access to its weather data API.

Example scenario: Your small business’s website has a form used to sign clients up for appointments. You want to give your clients the ability to automatically create a Google calendar event with the details for that appointment.

API use: The idea is to have your website’s server talk directly to Google’s server with a request to create an event with the given details. Your server would then receive Google’s response, process it, and send back relevant information to the browser, such as a confirmation message to the user.

Alternatively, your browser can often send an API request directly to Google’s server bypassing your server.

How is this Google Calendar’s API different from the API of any other remote server out there?

In technical terms, the difference is the format of the request and the response.

To render the whole web page, your browser expects a response in HTML, which contains presentational code, while Google Calendar’s API call would just return the data — likely in a format like JSON.

If your website’s server is making the API request, then your website’s server is the client (similar to your browser being the client when you use it to navigate to a website).

From your users perspective, 

APIs allow them to complete the action without leaving your website.

Most modern websites consume at least some third-party APIs.

Many problems already have a third-party solution, be it in the form of a library or service. It’s often just easier and more reliable to use an existing solution.

It’s not uncommon for development teams to break up their application into multiple servers that talk to each other via APIs. The servers that perform helper functions for the main application server are commonly referred to as microservices.

To summarize, when a company offers an API to their customers, it just means that they’ve built a set of dedicated URLs that return pure data responses — meaning the responses won’t contain the kind of presentational overhead that you would expect in a graphical user interface like a website.

Can you make these requests with your browser? Often, yes. Since the actual HTTP transmission happens in text, your browser will always do the best it can to display the response.

For example, you can access GitHub’s API directly with your browser without even needing an access token. Here’s the JSON response you get when you visit a GitHub user’s API route in your browser (https://api.github.com/users/petrgazarov):

Calling backend APIs from an Android client

  • On this page.
  • Generating the client library.
  • Setting up the project.
  • Configuring the project.
  • Adding the client library to the project.
  • Creating the service object.
  • Calling the backend API.
  • Making authenticated calls. Configuring your Android client to provide credentials.

I hope my interview experience will be helpful for you. Best of luck with your job interview.

Additional Reading

READ MORE

If you found this post useful, don’t forget to share this with your friends, and if you have any query feel free to comment it in the comment section.

Thank you 🙂 Keep Learning !


DeepCrazyWorld

Hey, I'm Deepika a professional blogger, web designer, Android developer and software engineer. I like to gain every type of knowledge that's why i have done many courses in different fields like engineering and technology. I love thrills and travelling to new places and hills.

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published.