Forum Discussion

Beryllium's avatar
12 years ago

Where's the API call being used?

Some legacy code on the lithium board I took over have the call below:

 

<#assign messages = rest("/topics/style/blog/recent?page_size=3").messages />

 

So where is this rest call explained?

 

 

At the API documentation pages the closest I can find is: https://lithosphere.lithium.com/t5/rest-api/bd-p/developers-rest-api?leaf-id=Blog.topics#Blog.topics.style.style.recent

 

However, the resource URL for that looks far different from the one used in the component I;m looking at. What's the discrepancy?

5 Replies

  • Isn't that exactly the same link I was linking too?

    My point is that the call as described in the API looks nothing like the call does when it's used.

    How does the resource description:

    "http://community.lithium.com/community-name/restapi/vc/topics/style/[style] /recent"

    Get translated into "topics/style/[style] /recent"

    I found that part to be confusing.

    Also, there's no description of what "[style]" should be in the documentation. How do I know that the options could be "blog" ?
  • AdamN's avatar
    AdamN
    Khoros Oracle
    12 years ago

    It's not the same, actually. What you linked was within a Blog context. What I linked was in a Community context. I thought that was the nature of your question. Apologies for the misunderstanding.

     

    Now that I understand your question better, let me try to address it. When you're working with the rest custom context object, you do not need to specify the full path. You can instead, specify a relative path because it's understood that the call is being made to the current community. So you can cut everything off at the http://community.yourdomain.com/restapi/vc, and just use what's after that for the call.

     

    Here's more about the "rest" context object:

    http://lithosphere.lithium.com/t5/developers-knowledge-base/Context-objects-for-custom-components-rest/ta-p/9333

     

    You can find the possible values for the "discussion_style" type here:

    https://lithosphere.lithium.com/t5/rest-api/bd-p/developers-rest-api?page=apicall

  • Thanks Adam,

     

    Some thoughts for lithium:

     

    1. So when I look at the documentation for both calls, they look very similiar except for the the example URL. It makes it very difficult to find the call as I'm sure you can see.  I find this to be a shortcoming of the documentation.

     

     

    2. Furthermore, why aren't the discussion_style options linked form the documentation page? I constantly feel like I need to look in a hundred different places for everything I'm doing. Why not make it easier for me by linking everything relevant next to the call.

     

    3. Actually having an example using a rest() call with the path would also have helped.

     

    4. In addition to the discussion_style, I also had no idea where to find the "rest" context object  options.

     

     

    Put those four together, and I've found that the lithium documentation is difficult at best. It's far too spread out, if you can even find it. There's a lot of improvement to be had here, and I think it would be rather simple to accomplish.

     

    Even now that I know this, when I later go to reference the API documentation, I will most likely find myself yet again in a spot where I need to find the possible values of discussion_style and the options for the rest context object. I have to book mark things and then find them there. Please consider better referencing within the docs.

  • SuzieH's avatar
    SuzieH
    Khoros Alumni (Retired)
    12 years ago

    Hi,

    I wanted to chime in here from the Documentation team to let you know that we completely understand your frustration and that we're working on making the documentation (across the Lithosphere and Developer Network) more manageable. We're working toward clear categories, less duplication, and more consistency overall. With regard to the REST API, we're in the process of reviewing the calls and getting better examples with complete parameter definitions. The first phase is coming in the next month for better REST API docs. Thanks for the detailed feedback. 

     

    Suzie