Shortcomings in Box APIs
While I'm exploring the Box APIs what I found out was that to work with any Files or Folders the API expects a File Id or a Folder ID. In my opinion these IDs are something generated internally by the Box Platform. For a customer application consuming the APIs it would be more sensible to work with meaningful names rather than IDs.
For ex:
Instead of saying
https://api.box.com/2.0/files/12345/content
it makes more sense to say
https://api.box.com/2.0/files/content?fileName=users.txt
Every time I create a File or Folder I also need to somehow save the ID information so that I can use that it to consume the APIs which makes it cumbersome.
This is just my observation and would like to see the comments from other Box API users/employees.
-
Hello ,
I think is a good thing to have ID 🙂
the approach you are suggesting has a setback as it is defined right now. The setback is the fact that the name of the file is not necessarily unique across the entire BOX platform, even probably not unique in your own account.
The ID of each file and folder is unique, as per what I understand, on the whole BOX cloud. That way, if some user shares a folder containing 100 documents with you each document has its own ID that will be completely different from all the documents you have. The only ID I have seen that is always repeated is the root folder that alwas is a 0.
Imagine a situation where you have to distribute a document to several teams, and as per how security works you need to copy that file across three different folder. Would you change the name adding suffixes or would you share as it is?
I understand that usually, when integrating with another platform you want to work with your own IDs and avoid having to store extra content... maybe then you can use metadata, fulfill a field with your own ID but then you will need a two-step process to search and then retrieve using box ID.
Let's see what other colleagues think 🙂
Regards
Please sign in to leave a comment.
Comments
1 comment