Suggestions and Inconsistencies

The HTTP & Python API
Post Reply
Posts: 7
Joined: September 9th, 2015, 10:00 pm

Suggestions and Inconsistencies

Post by danbradham »

Hello there!

Upon experimenting with the nim connectors for maya and nuke I found that they are too rigid to maintain the workspace we're used to. The api and connectors are also currently too intertwined to create my own app connectors. For the time being I've decided to go ahead and wrap the http api myself. This is fine, the core http api is simple and accessible enough to wrap quickly and efficiently in an object-oriented fashion. In this thread I'll maintain a list of suggestions and inconsistencies discovered in the process of exploring my own python api and app connectors.

Repo @

Here is what I've noticed so far:

Name fields in NIM vary: assetName, shotName, showname, jobname, server etc
These should probably all be just name. The query itself let's us know what object the name refers to.

There are also folder fields, path fields, os path fields, and mount points. These need some clarification overall.
The path field of a Server should probably refer to the operating system of the current user and not directly to linux.

In general I think the HTTP API could use an overhaul it would be great if it followed RESTful conventions. For example:

GET request to 1/user would return all users
GET request to 1/user/id would return a single user
PUT request to 1/user/id would update the user with the supplied data
POST request to 1/user would create a new user with the supplied data

This would be preferable to having a bunch of get uris and keep things grouped up nicely. All api methods referring to a user would live under the /1/user base uri. Things also more closely match the schema of your database at the end of the day. Here the 1 in the url refers to the first version of the api. So if you move towards a new api later on, you can leave these first uris in place as to not break legacy code.

For a really fantastic example check out the trello api:

User avatar
Site Admin
Posts: 336
Joined: June 24th, 2014, 8:10 am

Re: Suggestions and Inconsistencies

Post by andrew »


The API has evolved in many ways over the years and could definitely use a once over and I really appreciate your feedback on this. The main functionality of the connectors is wrapped up in the nim-core and we abstracted the application specific code to keep the overlapping work minimal. You'll notice though that things like NukeStudio are a departure using little overlap with the nim-core, which is probably more in line with what you are doing.

That's fantastic that you've started the repo. I'll keep my eye on what you are doing there and give insight where and when I can.

As far as the name fields, they vary due to matching the db columns and trying to maintain transparency. When the API does get an overhaul we can definitely consolidate and simplify where appropriate.

Path refers directly to the path that NIM will use to access any file or folder, hence why it overlaps with linux. But I agree that this could use some further clarification.

One of our goals when we do revamp the API to make it RESTful compliant, so we're on the same page. Once we get into this development I would be happy to share with you for your input and feedback.


Posts: 7
Joined: September 9th, 2015, 10:00 pm

Re: Suggestions and Inconsistencies

Post by danbradham »

Cool that's great news!

For the time being I'm exploring yet another avenue. Wrapping the database in an ORM using Python. The great thing about this methodology is that I can dynamically map all the database tables to models with very little code. This allows me to do everything I currently need via python, creating and modifying assets, tasks, projects, shows, shots, uploading files etc. What's left is to abstract the database session completely away from the user, and create a slim wrapper around the dynamic models to support a simpler and more pleasant api.

The tricky bit here is that the MySQL server is not accessible from outside the virtualmachine. The workaround is to modify /etc/mysql/my.cnf commenting out the line binding the mysql server to and adding '%' to the allowed hosts of the root user within the mysql database. Of course this makes your database a giant security risk, but, if you're running it internally and keeping it hidden from the web you should be OKAY.

Post Reply