Forum Discussion

luk's avatar
luk
Boss
11 years ago

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. with

 

http://community.lithium.com/restapi/vc

 

already this basic call (you can then put whatever api call you want behind the "vc", e.g. http://community.lithium.com/restapi/vc/<your_api_call>) gives back a response that contains all categories and some other stuff about the community...this is very helpful when debugging things as the actual response can be analyzed.

 

I thought it should be possible the same way with API v2 with a base url like

 

http://community.lithium.com/restapi/v2

 

but there is nothing coming back than a error 500 (sometimes a 403), tried various things like adding a query (urlencoded for sure) like http://community.lithium.com/restapi/v2/?q=SELECT%20count(*)%20FROM%20messages%20WHERE%20depth%20%3D%200

 

but no luck...am I maybe trying to use the wrong url or this this not possible at all with API v2 without implementing the oAuth flow described above??

 

PS: I'm aware of the API Browser in the backend, but it's about accessing the API v2 via browser address bar directly

 

EDIT: I guess/hope I found the "problem", it's described here: http://community.lithium.com/t5/Community-API-v2/Getting-started/ta-p/113193 in the section "Make a LiQL query over HTTP", looks like 1) the URL to call is different, e.g.

 

http://<eu (depending if your community is hosted in Amsterdam or in the US)>.api.lithium.com/community/2.0/search?q=<query>&client_id=<this_is_the_problem>&api.pretty_print=true

 

and we need to request that client_id from Lithium support...did that but no response yet, so can't tell if this is really the issue, but most likely =)

7 Replies

Sort By
  • luk's avatar
    luk
    Boss
    11 years ago
    Yes, but it's not very intuitive/consistent =)
  • JeffY's avatar
    JeffY
    Lithium Alumni (Retired)
    11 years ago

    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.   

  • luk's avatar
    luk
    Boss
    11 years ago
    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?
  • JeffY's avatar
    JeffY
    Lithium Alumni (Retired)
    11 years ago

    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.   

  • JeffY's avatar
    JeffY
    Lithium Alumni (Retired)
    10 years ago

    Hi dhiraj_gophane -- While that approach may work temporarily, it is not officially supported and will likely be turned off in the future.   The officially supported path is to use OAuth via the API proxy.