32

I'm trying to write a "standard" business website. 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.

Improve this question

4 Answers 4

Reset to default
38

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
6
  • I have a really dumb question. Is this the essence of Service Oriented Architecture?
    – johnny
    Dec 19, 2015 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, 2015 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, 2019 at 12:17
  • 1
    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, 2020 at 1:42
  • 2
    I'd argue that "API" isn't being used as "publically accessible web service", but rather "non-HTML-returning web service".
    – Flater
    Dec 27, 2020 at 13:54
14

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 explicitly 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 version, 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
2
  • 10
    Actually frontend is the client side code (HTML, Javascript) and backend is the server code (PHP, Python, Ruby).
    – Pithikos
    Feb 12, 2018 at 11:31
  • I'm not sure I agree that APIs are restricted to calls outside its own process. I think it is fairly common to call the public methods of a library an API.
    – JonasH
    Nov 8, 2021 at 14:47
1

Start with the right picture

where does the API come into this picture?

It looks like you need to have the correct diagram in mind to work with:

enter image description here

Breaking it down:

  • the front-end view-controller is all about GUI behavior and it's coded with JavaScript
  • the view-controller javascript calls the web-service in a way that conforms to an agreed protocol - the API. This is the entry-point to the back-end.
  • the API is the agreed way that the front-end and back-end will work together. This is structurally implied with matching code, and explicitly planned with documentation.
  • the web-service ultimately is about data storage and retrieval in the backend database
  • (sometimes a web-service might be a gateway to another third-party web-service in turn. EG. PostMark for Emailing)

For completeness:

Does the front-end call the back-end which calls the API?

No. The "Web Service" is the practical thing that is "called". API is the agreed standard for the names of the URLs, format of data, and purpose of each URL.

Or does the front-end just call the API instead of calling the back-end?

No. The "API" is not "called". It's documented, and both front-end and back-end teams share that information to meet in the middle.

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)?

No. The back-end is very broad. While the front-end is all contained within a browser, the back-end is everything else often across multiple devices: CDN, Web Server, Application Server, Web Service endpoints, Database, Schema,....

(There are actually two "controllers": one for the GUI behaviour in the browser, the other is the Application-Server. But more specifically, there are usually many Web-Services hosted in an Application-Server. Each Web-Service is a kind of controller, and the Application-Server routes to the right Web-Service.)

More insight :-

It's about teams of people

Front-end and Back-end is usually more about the teams and what they do. Front-end people are more like graphic designers, they care about alignment, whitespace, user tasks, colour, fonts, wording, information hierarchy. Back-end people are more like engineers and like to solve technical problems. Both are creative.

Conceptually:

  • The frontend is the GUI which needs data
  • The backend is everything else: the Data/Schema, Security, Processes, and Infrastructure that runs it all

These underlying concepts help as a guiding light, because in practice, it gets muddled up by prevailing limitations, customs, and best-practice.

Limitations, customs, and current best-practice:

  • In practice: A dynamic webpage is half-half. It's generating HTML (frontend), but getting data to mix in (backend). For a Single Page Application or AJAX application. It is simply front-end.
  • Limitation: A Web Browser wants to speak HTTP to get the data.
  • Custom: A web-service is used so the web-browser can get data. (This is not doing GUI, so it's definitely back-end)
  • Emerging: GraphQL is a relatively new way so the Web Browser can connect to a single endpoint that can simply expose access to the underlying database more generally.
Improve this answer
-3

A REST 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.