Provide ability to return only required data

[sukhpalsingh]

I think it will be good if we add the parameters such as include=gurmukhi,eng_translation,eng_transliteration and so on so that only required data is returned in the resuls.

It will also good for your server to reduce the data transfer otherwise it will be returning the unnecessary data for every request and will increase the bandwidth data.

By default only return the gurmukhi, english translation and english transliteration and then others can be included using the 'include' parameter.

What you think?

[sarabveer]

This has been requested by others, I will look into implementing this into APIv3.

[davchana]

Hi, appreciate this lean data service; but please announce this so that we can change/update our apps. Or better; serve the new api on new version; and retire the existing one in few weeks after that.

I have already subscribed to notification of this repo.

[sarabveer]

Yes, APIv2 will remain unchanged and will be served for apps who still need to use it.

APIv1 is still up to this day, even though it is 3-4 years old at this point.

[Shavinder]

SSA,
Is it possible to fetch just data from a given granth by specifying pages start and end numbers? For example get data from Bhai Gurdass ji diyan Vaaran from pg 1 to 50?

[sarabveer]

@Shavinder Bhai Gurdas Ji Vaaran Page Numbers represent the Vaar No, which only goes up to 41.

Also, if you fetch a "page" from Bhai Gurdas Ji Vaaran, it returns the whole Vaar, which is big and will take time to load.

If you request all the Vaars, from 1 to 41, then that will be REALLY BIG file and will take forever for the client to load.

[Shavinder]

@sarabveer Thank you for your reply. I do not intend to use this in an online application. I just needed text to use offline, on my laptop, and my phone, for my own study, contemplation and research. I specifically need Bhai Gurdass Baani and Dasam Bani. This will be private use. Can you share text with me? I'd be grateful.

[sarabveer]

@Shavinder At the moment, I do not have any protocol in place for sharing raw text from the Gurbani Database.

[sarabveer]

Here is a preview of Today's Hukamnama in APIv3 (This is the only endpoint that is live ATM).

https://devapi.gurbaninow.com/v3/hukamnama/today

As you can see, this is using the new Gurbani Database which is being done from scratch (which is still in WIP), but the amount of data in the JSON has increased, mainly due to Mahan Kosh. This is a reason to implement the feature to only return requested fields.

I would like comments on the new APIv3 response structure before re-using it for the other endpoints.

[davchana]

@sarabveer Very great Sewa Ji Bahut hi nice..

Some Suggestions:

1. Can all viakhya can be moved to its own object? i.e the current structure is:

Current:

root :
  ...
  hukamnama :
    [i]:
      line:
        ...
        punjabi:
          default:
          gianiharbhanssingh:
          faridkotteeka:
          bhaimanmohansingh:
          mahankosh

My Suggestion:

root:
  ...
  hukamnama:
    [i]:
      line:
        ...                 //many keys
        punjabi:
          default:
            .....
          others:           //new addition from here onwards
            [0]:              //array first entry
              name: gianiharbhanssingh:
              text:
              arth:
              source:
              notes:
              reference:
            [1]:
                 // same as above
            mahankosh:
                  ....

Reasons:

• Current object uses writer/source as object key; api consumers need to know the exact writer name; any new writer/source additions in api json will force the apps to be adjusted. If this all is put in a simple array; apps can just loop & consume the data. although we could just itriate over key names too. The other keys, like text, arth, source, notes, ref can be empty as per source.
• Is it possible to add a lean hukamnama/shabad endpoint, defining the languages/teeka-sources etc?
• Please add an key/value pair showing the pass/fail status of api's connection & processing of hukumnama source. I.e. if api connected successfully to source for hukumnama at 9PM or 12 EST & if it fetched & processed & stored?

:)

will continue to add more

[sarabveer]

This is will be solved by exposing the GraphQL API