For the short answer, read the last paragraph.
i have been using my Node.js command line sample and cannot reproduce what you are describing.
I executed the following commands:
- node forge-promise.js 2legged
- node forge-promise.js bucketCreate cyrille20160916a
- node forge-promise.js upload samples/Au.obj
-> get a response with location = https://developer.api.autodesk.com/oss/v2/buckets/cyrille20160916a/objects/Au.obj
- node forge-promise.js translate Au.obj
-> get a response with urn = dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Y3lyaWxsZTIwMTYwOTE2YS9BdS5vYmo
- node forge-promise.js translateProgress Au.obj
-> when I got a completed translation
- node forge-promise.js manifest Au.obj
- node forge-promise.js html Au.obj Au.test
-> here I generate a file using the recommended production server and latest viewer version 2.9
Using the https://developer.api.autodesk.com/viewingservice/v1/... is fine but not recommended for production. v1 in this case is unrelated to the REST API you are using for OSS or DM... it is the viewing service version, so you do not need to worry.
OSS version v2 is not available and should be preferred to version v1 (see documentation here for v2 OSS. You will see for example that it says https://developer.api.autodesk.com/oss/v2/buckets/.
Now the DataManagement API is versioned as v1 (i.e. https://developer.api.autodesk.com/project/v1/hubs) but that does not has any relation to the Model Derivative v2 API. v1 in this case only means that we have release:
- OSS v2
- Data Management v1
- Model Derivative v2
and are the latest API available. With REST API, data is backward/forward compatible, only the REST call are versioned, but should work fine all together. For example and highly not recommended for future, you may decided to use the old viewing service v1 to start the translation, using OSS v2 or v1, and everything should continue to work today (as September 2016), but these 'old' API will be retired in future.
Now if you got a a problem with one or another API, maybe you can share with us a code sample / snippet, so I better understand the issue.
An error 404, means that the resource wasn't found, which can translate in multiple causes. For example a base64 encode string, a non urlencoded parameter - but with the new Model Derivative API (i.e. v2) when you post a translation job, and request the manifest immediately after, you will get a 404 error because the manifest does not yet exist. It would exist only when the translation Job has really started on the server. And depending how busy is the server, it can take many 'seconds' (up to a minute or two). I believe this is the issue you are facing, but if not please provide me a code sample.