0

I'm confused about the meaning of API, specially in the context of REST. I'm thinking of one example.

My company creates an application that runs on a server (the "backend"). (JavaScript in Node.js)

To use it, my company also creates a user interface that runs on the browser of the client's computer (the "frontend").(React.js).

When the user enters www.my-company.com, they are provided with our frontend. They click around it which sends specific requests that access specific methods "exposed" in our backend. It responds with mostly JSONs with data.

The backend is made to be accessed only by our frontend. We don't want anything else making requests to it.

Question 1: Is the service that I just described "an API"? A lot of people talk about "developing APIs" and I want to know if that's what we are doing.

Question 2: Is our service benefited by making it REST? After reading about it I think it only benefits services that can be accessed "by anyone's app", instead of "just by our website".

Improve this question
5
  • please don't cross-post: stackoverflow.com/questions/76356691/… "Cross-posting is frowned upon as it leads to fragmented answers splattered all over the network..."
    – gnat
    Commented May 29, 2023 at 13:04
  • @gnat i was told there to post here... and here im being told to post there?
    – Juan Perez
    Commented May 29, 2023 at 15:16
  • 1
    @JuanPerez - it's just that the exact same question shouldn't be posted on more than one site at the same time, because this is a Q&A site, and those looking for a potential solution might stumble upon one, but not the other, etc. (Decide where you want to post, then delete the other). Regarding your question - it's a bit of a terminology mixup that's proliferated in recent past. When people say they are developing "an API" 1/2...
    – Filip Milovanović
    Commented May 29, 2023 at 15:31
  • 2
    ...what they mean and what they should be saying is that they are developing a web service, which includes defining the endpoints, request and response bodies, etc. - this set of endpoints and data structures, along with what they are for, what they do from the consumer perspective, is the interface to the service - a.k.a. its Application Programming Interface (API). The API as a concept is not specific to web services, and does not have to be realized through web requests - e.g. any component, library or framework has an API, a database has an API, etc. 2/2
    – Filip Milovanović
    Commented May 29, 2023 at 15:31
  • FYI: The backend is made to be accessed only by our frontend. We don't want anything else making requests to it. this is not possible once your web app is published (no matter if it's server-side rendering or SPA-API). The app is visible to everyone, endpoints are visible to everyone, and sites are accessible by all sorts of bots and scrappers, you can't prevent this from happing unless you add a security component in front. Don't conflate accessibility with authorization.
    – Laiv
    Commented May 30, 2023 at 11:57

2 Answers 2

Reset to default
6

  1. Yes, what you describe is an API. Any software interface which is designed to be called by software clients is an API. Your architecture sound like RPC (remote procedure calls) over HTTP, which is a common form of API.

  2. Probably not. REST is not designed for API's. REST is an architectural style optimized for large-scale distributed hypermedia. It is not designed for API's like yours, where a single frontend communicate with a single backend.

Improve this answer
3

I don't disagree with JacquesB's answer per se but the answer kind of depends on what you mean by RESTful. If you mean using HTTP verbs correctly and structuring your API around the concept of resources, then I would say definitely yes, it can be helpful. For example, simply using GET for retrievals and following the requirements that it be 'safe', you can get client-side caching with no additional effort. It also often leads to easier integration with client-side libraries that expect you to conform to these standards. As far as we know, you may already be doing this.

But if you are talking about REST as defined by Fielding such as HATEOAS (worst acronym ever) and other more hifalutin kind of ideas, it's probably overkill.

Improve this answer
9
  • 1
    @JacquesB: The argumentation for any client-side cache remains the same regardless of what specific data (or data format) is being cached.
    – Flater
    Commented May 31, 2023 at 6:12
  • 2
    @JacquesB The argumentation for any client-side cache remains the same regardless of what specific data (or data format) is being cached. The argumentations for client-side caches and serverside caches are different, but individually they are consistent for any kind of data that you are working with, regardless of it being JSON data, images, web pages, ...
    – Flater
    Commented May 31, 2023 at 6:16
  • 1
    @JacquesB: I can make the same argument about browsers being able to store the result they get from a URL and not fetch it a second time. The reason for wanting to cache something is irrespective of the specific data format that is being cached.
    – Flater
    Commented May 31, 2023 at 10:48
  • 1
    @JacquesB "which means the code already have the data!" Not necessarily. Data, especially from APIs can change. And you do things like put in a If-Modified-Since header to only pull data when it is actually changed on the server. I've never understood why you wouldn't follow HTTP standards when you can. Did the SOAP-WSDL debacle teach us nothing?
    – JimmyJames
    Commented May 31, 2023 at 13:23
  • 1
    @JacquesB HTTP level caching is not necessarily happening client-side, but may occur in the intermediaries in the network infrastructure, making responses faster and taking the load off of the server.
    – Filip Milovanović
    Commented May 31, 2023 at 20:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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