3

I am building a website which has a single page app frontend that connects to a REST API from the backend. I also want others to be able to write programs for this website.

It seems like providing public access to the same API I build my frontend in would be useful. There would only be one API to maintain and I know every single feature of the website is available for 3rd parties.

Are there any cons to this approach?

Some things that come to mind is letting 3rd parties use the same API as I use myself for the frontend might hold back development as new features and changes can't be released right away. Another is that I'd probably want to have a system that allows users to give permissions to 3rd party tool such as allowing making posts but disallowing changing user settings. I'm not sure how well this would work while sharing the same API.

Improve this question

2 Answers 2

Reset to default
5

As long as your own web app is the only program which accesses that API, API changes don't need to be backwards compatible, since you will update your single page app immediately.

But as soon as you publish an API to the world, you need to care strictly for backwards compatibility, otherwise the other devs writing programs which consume your API will become very unhappy if their programs stop working with every new release of your API.

So either you go the route described by @RobertHarvey in his excellent answer, or you make some stable parts of the API public, and keep other parts internal.

Improve this answer
2
  • Even if it's not open to the world. If you ever have to maintain different clients (web, mobile, sensors, etc) you will realise that they evolve independently from each other. While changing your SPA is easy, changing the mobile APP it's not due to nobody can assure you that everybody will update the app. In IoT is even worse, because the client shipped within the device probably will never change. Commented Jan 9, 2018 at 10:18
  • @Laiv: you are correct. I would like to emphasis that it makes a huge difference if the vendor of the API is also the vendor of the client apps, or not. If the vendor is the same, they can always publish the API and a new version of the client application simultanously. Then the old client app can check the availability of an update, and install it automatically if required. However, if I offer a version of an API to third parties which I have no contract with, I can not expect them to invest time to update and deploy their client applications immediately when my new API version is published. Commented Jan 9, 2018 at 10:29
6

While it is possible to write a single API that services both your external clients and your web/desktop clients, you will get better fit, form and function by creating separate API's.

The reason for this should be self evident: the use cases for your public clients will almost certainly differ from those of your frontend. For example, you may have a dropdown or collapsible list on one of your forms that's populated from a specific API endpoint, an operation that your clients may not have the slightest interest in. Or, you may simply have functionality in your frontend that you don't want to expose directly in your public API.

Of course, nothing prevents anyone from reverse-engineering your web page to determine how your unpublished API works. That's where securing your website/api comes in. Many frontend API's simply expose a REST interface, a leaky CRUD abstraction that requires insider knowledge of the database architecture to use properly. You might want your publicly-sanctioned API to be a bit more nuanced than that.

So for all of these reasons, you have to decide whether or not you want to design a single API or (more likely) two separate ones, and whether or not they need to be secured.

Improve this answer
2
  • Are you missing 'or' between 'REST interface' and 'a leaky CRUD abstraction'? 'Cos (notwithstanding idiots who create CRUD RPC over HTTP and call it REST) that isn't what REST is. Commented Jan 9, 2018 at 11:04
  • @PeteKirkham: By "leaky abstraction," I mean that the CRUD/REST interface essentially exposes the database design. Commented Jan 9, 2018 at 15:53

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.