A valid use-case is to provide a UI for API products (Stripe, Lob, Twilio, etc). The main product is an API for customers to use but you may also want to be able to login to their website and check the current state of affairs of your account. Since you already have to build an API for your customers and everything you're showing might already be possible with the API, you can create a UI to glue the request calls together. A SPA can use the same API, avoids you having to write new code for your website and you get to dog-food your own API.
Using the front end as the glue sounds dangerous. If you are accessing a third party api via the front end directly I can't see a way around passing whatever authentication mechanism they use to the client. This is giving pretty open access to hit the api with your credentials.
In this case it’s not a third party API but your own products API. Also while you can use the same endpoints, authentication and authorization don’t have to be the same. You could use your standard basic auth (or other) for your regular API use case and then use cookie based auth or JWTs (or whatever other auth you want) for the SPA. Again this isn’t for third party APIs but for companies creating a web app for their own apps so you can have flexibility.
Comments
A valid use-case is to provide a UI for API products (Stripe, Lob, Twilio, etc). The main product is an API for customers to use but you may also want to be able to login to their website and check the current state of affairs of your account. Since you already have to build an API for your customers and everything you're showing might already be possible with the API, you can create a UI to glue the request calls together. A SPA can use the same API, avoids you having to write new code for your website and you get to dog-food your own API.
Disclaimer: I work for Lob.
Using the front end as the glue sounds dangerous. If you are accessing a third party api via the front end directly I can't see a way around passing whatever authentication mechanism they use to the client. This is giving pretty open access to hit the api with your credentials.
In this case it’s not a third party API but your own products API. Also while you can use the same endpoints, authentication and authorization don’t have to be the same. You could use your standard basic auth (or other) for your regular API use case and then use cookie based auth or JWTs (or whatever other auth you want) for the SPA. Again this isn’t for third party APIs but for companies creating a web app for their own apps so you can have flexibility.