APIv2 directly from browser.
(In response to this article) I'm not quite sure if this is related to the issue I'm facing, but could be:
With API v1 it was always possible to access the api directly from the browser, e.g. w...
Forum Discussion
This is not an issue but how V2 is designed to work.
Yes, but it's not very intuitive/consistent =)
Hi Luk -- Sorry for the confusion. You are correct that to access API v2 over HTTP you need to use OAuth and a different base URL than v1. The reason is actually to simplify the developer experience. All Lithium APIs whether from community, LSW, LSI, or any other product will, going forward, use the same base URL (which points to an API proxy on our end) and use the same authentication mechanism. This should make it easier for developers to leverage the full suite of Lithium APIs. Further, by creating a proxy, we're able to scale easier and monitor better which means improved uptime and reliability. Thanks for bearing with us during the transition.
- Hi Jeff,
thanks for the insight!
I actually received the client_id(s) from Lithium support, but unfortunately they do not make it possible to make a REST v2 request via browser, it just times out, no matter what...support case is still open, guess they are looking into it, but I think the docs should may be updated and say that this is not working like explained above...do you have an example URL which I can call and which returns data successfully?
Regarding the Proxy, what about DoS attacks on that proxy....wouldn't that bring down all communities worldwide (that use REST v2 via this central proxy) if somebody manages to do a successful one?Hi luk -- There are a few additional steps required once you have the client_id. For example, you need to make requests for OAuth access and refesh tokens. If you haven't been through all the steps in the linked document, I'd recommend you start there; otherwise, I'm sure Support is researching the specific details of your problem.
Re: the proxy, it's highly available and scalable to protect against that risk. This design is pretty common for large-scale SaaS companies.
