You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a half-hearted proposal, but worth looking into, probably.
The REST API has proven to be trouble in a number of respects, including:
regular discrepancy between docs and actual server behavior.
bugs related to inconsistent field formats in responses.
serious problems with performance in certain cases.
Part of the benefit of using the REST API comes from the fact there's a public spec which the server should adhere to.
They should, but as noted above there are frequent causes to file bugs. Unfortunately, filing bugs with Autodesk does not mean they will get fixed in our lifetime.
The Python API, otoh, is fairly stable, so it's not ridiculous to consider switching our approach to focus on a plain port of the Python client.
Tracking changes over time should not prove to be awful since updates from the vendor come so rarely. The downside is we will have to reverse-engineer many HTTP payloads to ensure we get the coverage we need in tests. Assuming the Python client has a reasonable test suite we can port, that'll give us some decent guidance.
This will mean huge breakage in the public API of the crate since much of the status quo depends on consuming payloads structured in that specific JSON API layout.
The text was updated successfully, but these errors were encountered:
This is a half-hearted proposal, but worth looking into, probably.
The REST API has proven to be trouble in a number of respects, including:
Part of the benefit of using the REST API comes from the fact there's a public spec which the server should adhere to.
They should, but as noted above there are frequent causes to file bugs. Unfortunately, filing bugs with Autodesk does not mean they will get fixed in our lifetime.
The Python API, otoh, is fairly stable, so it's not ridiculous to consider switching our approach to focus on a plain port of the Python client.
Tracking changes over time should not prove to be awful since updates from the vendor come so rarely. The downside is we will have to reverse-engineer many HTTP payloads to ensure we get the coverage we need in tests. Assuming the Python client has a reasonable test suite we can port, that'll give us some decent guidance.
This will mean huge breakage in the public API of the crate since much of the status quo depends on consuming payloads structured in that specific JSON API layout.
The text was updated successfully, but these errors were encountered: