I'm trying to write a "standard" business web site. By "standard", I mean this site runs the usual HTML5, CSS and Javascript for the front-end, a back-end (to process stuff), and runs MySQL for the database. It's a basic CRUD site: the front-end just makes pretty whatever the database has in store; the backend writes to the database whatever the user enters and does some processing. Just like most sites out there.

In creating my Github repositories to begin coding, I've realized I don't understand the distinction between the front-end back-end, and the API. Another way of phrasing my question is: where does the API come into this picture?

I'm going to list some more details and then questions I have - hopefully this gives you guys a better idea of what my actual question is, because I'm so confused that I don't know the specific question to ask.

Some more details:

  • I'd like to try the Model-View-Controller pattern. I don't know if this changes the question/answer.
  • The API will be RESTful
  • I'd like my back-end to use my own API instead of allowing the back-end to cheat and call special queries. I think this style is more consistent.

My questions:

  • Does the front-end call the back-end which calls the API? Or does the front-end just call the API instead of calling the back-end?
  • Does the back-end just execute an API and the API returns control to the back-end (where the back-end acts as the ultimate controller, delegating tasks)?

Long and detailed answers explaining the role of the API alongside the front-end back-end are encouraged. If the answer depends on the model of programming (models other than the Model-View-Controller pattern), please describe these other ways of thinking of the API. Thanks. I'm very confused.


I think you're being confused by the way the term API is being misused and abused by many web developers.

  • API means Application Programming Interface, i.e. any officially specified interface between different systems (or parts of the same system).
  • Some time ago, it became a big thing for web startup to offer public access to some of their internal data through a web service API, typically using REST and JSON, thus allowing third-party developers to integrate with their systems. Web developers started using the term "API" to mean specifically (and only) "publically accessible web service", and misusing it to include the implementation thereof.
  • In terms of frontend and backend, this web service API (and its implementation) is the backend. Some parts of it may be publically accessible and others only to your frontend.
  • A different name for this is "service layer", i.e. code that
    • represents services which the frontend calls
    • contains no display logic (that's the job of the frontend, after all)
    • is more abstract and coarse grained than simple CRUD actions (one service call will often involve multiple CRUD actions and should be executed within a database transaction).
    • contains the business logic of the application
| improve this answer | |
  • I have a really dumb question. Is this the essence of Service Oriented Architecture? – johnny Dec 19 '15 at 19:51
  • @johnny: no - SOA is a concept at a much higher level of abstraction, it's more about how you organize your business functionality than about technical layers. – Michael Borgwardt Dec 20 '15 at 20:29
  • I wouldn't call it misuse though. Perhaps "rebranding"? It is the same with "MVC" which is in context of webdevelopment something completely different than in times of PARC when the term was coined. – Thomas Junk Dec 7 '19 at 12:17
  • The backend serves the front-end and usually return view models composed of more than one business model. Very often these business model composites are stripped down to fit the current view and sometimes "artificial" properties may be added to serve the view context to execute matching logic in the backend. It means that backend handles MULTIPLE business models at once, while an API is segmented around INDIVIDUAL business models, unaltered, doing CRUD basic functions and sometimes more complex operations. These days, API can be used as a backend but would require many calls to fill a view. – formixian Oct 8 at 1:42
  • By no means my previous comment be taken as an absolute truth. It is a rule of thumb that has many gray spots. I'm pretty sure there is alo of API out there that do not fit perfectly in the box I drawn. On another hand, it is a good "general" way to categorize these two concepts IMHO. – formixian Oct 8 at 1:48

Let us sketch out a "typical" website's architecture, with both a "front-end" and a "back-end". And since it's a website, we'll also explicity have a "client". (Since there's no way for JavaScript in a browser to call MySQL on a server directly.)

For clarity, the terms we're using are:

  • Client: The HTML5 compliant browser, esp. the DOM and the JavaScript there loaded to manipulate it.
  • Front-End: The PHP server that the DOM is pointed to, containing both the individual page requested and some AJAX style XML or JSON access points.
  • Back-end: A database server, where MySQL runs.

For a properly designed program, each of these components has a private API to communicate with the others. The "front-end" PHP code does not issue arbitrary SQL SELECT statements directly, but rather calls stored procedures, pre-authorized SQL, or even distinct PHP calls to an entirely different instance of PHP that runs on the back-end server. These stored procedures or distinct HTTP calls are themselves an API.

The definition doesn't change even if we allow for some impurity of our design. If your PHP file writes and sends a SQL string directly to MySQL, IT IS STILL AN API, albeit a very unusual one that you are unlikely to repeat.

Note that it's entirely possible to have your front-end php be strictly synchronous, with no AJAX voodoo whatsoever. If you call the same external PHP functions in said synchronous file, you could consider them as using the same API as the client-side verison, although use of the term "API" here may not give any real clarity.

An API as an Application Programming Interface, after all, and really refers to any time one program calls outside of its own process. If you're writing a project that has both a front-end and a back-end, be those AJAX/PHP/MySQL as above or MS Access/SQL Server, it's worthwhile to specify explicity how you'll be calling each other, if for no other reason than to make it easy to know where to look when something breaks.

(And the topic of public API is something else entirely. In our example above, only the URL displayed in the client is a "public API." Everything else is, in essence, "private." As in, you don't expect any code beyond your control to call your internal API, and you either deny such results outright or reserve the right to do so in the future.

| improve this answer | |
  • 5
    Actually frontend is the client side code (HTML, Javascript) and backend is the server code (PHP, Python, Ruby). – Pithikos Feb 12 '18 at 11:31

an API handles http requests such as GET, POST, FETCH, DELETE... which can be used depending on your token access to retrieve data in specific format such as json, xml, etc.

This "data" can be used into your own application to get API (Application Programming Interface) which is a public accessible web service to gather data which might be interesting to some audience.

This data might return a set of data representing it failed or retrieve data from it's API server

API is meant to be back end so it can be used in any front end environment. This means it can be used in a web, android, ios... application that can handle https requests

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.