How to handle exposing an API that is consumed by client side code on a website.

Not applicable

Posting this on behalf of a customer.

We are helping a team design an API that will expose store stock position. For example this would enable a consumer to search for a product within a location, to see if the item is in stock. The same API would be used by all consumers: Desktop web, mobile web, mobile native apps and third parties. The current thinking is to have the API accessible by the front end code base and it would be called by javascript. We would use a key to identify the consumer, and this would have a high quota for mobile web or desktop web due to the potential number of users. However, it would be relatively easy to go through our front end code and retrieve this key. This would enable someone to either aggressively attack or crawl this endpoint.

Are there any design patterns, guidelines or recommendations for exposing this kind of APIs?

--SF913450--

0 4 553
4 REPLIES 4

How about using client-credentials oauth for securing your api?

Hi Cladius, thanks. I should have mentioned that this was for anonymous users too (so definitely much more susceptible to bots too)

adas
Participant V

A good way to get started with API Design would be to follow the eBook: API Facade Pattern

You can download your free copy from https://pages.apigee.com/api-facade-pattern-ebook....

adas
Participant V

@Oliver.Ogg If you want to expose the API to trusted partners only, you can use the Access Control policy, which would do IP based filtering of the incoming requests and only allow specific IP ranges chosen by you. If you want further protection and safe-guard against a potential DOS attack, you can use the ratelimiting policy known as Spike Arrest in Edge. You can rate limit based on an identifier, which can be the x-forwarded-for header or client-ip.