Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

up vote 6 down vote accepted

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
share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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