4 ms·
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 abl
by dmlittle 7y ago
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.
- jklein11 7y agoUsing 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.
- dmlittle 7y agoIn 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.