I'm about to embark down the path of writing a .NET app for retrieving and updating title Ratings in .NET. I was hoping to find a reference to the XML Schema that's used to format the data returned by the REST APIs, so I wouldn't have to hard-code every detail of the schema into my app.
I've been through most of the pages of the Developer documentation and I noticed one URL that seemed like a promising lead (http://schemas.netflix.com/catalog/programs) but it appears that the service "schemas.netflix.com" is not currently (no longer?) running.
Is there somewhere I can find a place to point Visual Studio to find the current XML Schema for the data returned by the Netflix APIs?
The schemas subdomain is just for URIs representing types in our system. Not being full-fledged URLs, they don't resolve. We don't provide a schema at this time.
Can you (or others) tell me (us) what use the URIs have, if not as full-fledged URLs or services?
Can you (or others) give us any guidance on how we should approach the XML data layout that is retrieved from the Netflix API? Should we simply assume that the XML defacto schema (as it is today) is subject to change at any time, and should not be relied upon as a stable set of elements & attributes?
Are most developers simply hard-coding the current schema into their applications, with the proviso that they'll have to rip & replace at the next update?
Think about URIs as pure type information. For example, you often see them used to add type information via rel attributes in links.
While we don't provide a schema we take care not to break our interface contract with developers. Note that we don't consider adding new attributes, elements or entirely new API resources as breaking the contract, only when we move, remove or change an existing aspect of an API request or response.
When we do introduce changes we feel break our contract we'll version the API (see the Conventions topic on versioning) and allow the old version to run in parallel a number of months to allow developers to update their applications if they are affected by the changes. We tend to queue up these contract breaking changes so that we only have to version the API rarely. I expect we'll version the API for the first time in 3-6 months.
For example, we realized that we weren't following the same category scheme in catalog/index that we were using in other API resources. To avoid breaking our contract, we added "deprecated=true" to the old categories and introduced the new categories alongside. The deprecated categories won't be removed until we introduce the next API version.
A great example of why REST is horrible for developers. We NEED a schema to go by. Simple building out classes based off of the *example* responses you provide does not gaurantee that we will see every element/attribute the schema has to offer. Surely there is a reference document detailing each response somewhere!
As a side note and to further detail why I hate REST, it will take a developer a good solid few days to implement the entire Netflix API in REST (assuming they do it "right") whereas with SOAP it is literally about three clicks and you're done.
I'm about to embark down the path of writing a .NET app for retrieving and updating title Ratings in .NET. I was hoping to find a reference to the XML Schema that's used to format the data returned by the REST APIs, so I wouldn't have to hard-code every detail of the schema into my app.
I've been through most of the pages of the Developer documentation and I noticed one URL that seemed like a promising lead (http://schemas.netflix.com/catalog/programs) but it appears that the service "schemas.netflix.com" is not currently (no longer?) running.
Is there somewhere I can find a place to point Visual Studio to find the current XML Schema for the data returned by the Netflix APIs?
Thanks all!
Message edited by ParanoidMike 2 years ago
Tags
Michael Hart – 3 years ago
The schemas subdomain is just for URIs representing types in our system. Not being full-fledged URLs, they don't resolve. We don't provide a schema at this time.
ParanoidMike – 3 years ago
Thanks for your response Michael.
Can you (or others) tell me (us) what use the URIs have, if not as full-fledged URLs or services?
Can you (or others) give us any guidance on how we should approach the XML data layout that is retrieved from the Netflix API? Should we simply assume that the XML defacto schema (as it is today) is subject to change at any time, and should not be relied upon as a stable set of elements & attributes?
Are most developers simply hard-coding the current schema into their applications, with the proviso that they'll have to rip & replace at the next update?
Thanks again, Mike
Michael Hart – 3 years ago
Hi Mike,
Think about URIs as pure type information. For example, you often see them used to add type information via rel attributes in links.
While we don't provide a schema we take care not to break our interface contract with developers. Note that we don't consider adding new attributes, elements or entirely new API resources as breaking the contract, only when we move, remove or change an existing aspect of an API request or response.
When we do introduce changes we feel break our contract we'll version the API (see the Conventions topic on versioning) and allow the old version to run in parallel a number of months to allow developers to update their applications if they are affected by the changes. We tend to queue up these contract breaking changes so that we only have to version the API rarely. I expect we'll version the API for the first time in 3-6 months.
For example, we realized that we weren't following the same category scheme in catalog/index that we were using in other API resources. To avoid breaking our contract, we added "deprecated=true" to the old categories and introduced the new categories alongside. The deprecated categories won't be removed until we introduce the next API version.
Quantum Concepts – 2 years ago
A great example of why REST is horrible for developers. We NEED a schema to go by. Simple building out classes based off of the *example* responses you provide does not gaurantee that we will see every element/attribute the schema has to offer. Surely there is a reference document detailing each response somewhere!
As a side note and to further detail why I hate REST, it will take a developer a good solid few days to implement the entire Netflix API in REST (assuming they do it "right") whereas with SOAP it is literally about three clicks and you're done.