KEEP IN TOUCH CALL US: 877 513 3118
Next December 19 I will be closing the year speaking about Security Architectures for modern applications at Argentine National Technological University in Buenos Aires.
The National Technological University (Spanish: Universidad Tecnológica Nacional, UTN) is a country-wide national university in Argentina, and it’s considered among the top engineering schools in the country, so It is a great honour to be invited to speak there.
On my talk I will covering
Token-based Authentication scenarios for Single Page and Mobile Apps, access delegation with
OAuth 2.0 and Identity Federation with
OpenId Connect, as well of having fun teaching how to hack bad implemented sites.
If you are on Buenos Aires at that time I hope to see you there! Sign-up here!
Versioning the Web API URL is probably one of most common choice among developers. Well-known APIs such as Twitter, Github or Facebook use this approach, but it does not mean it’s the best way to do things. It presents some of the issues discussed below.
For example. You have two resources /orders and /customers. You need to introduce a new version to accommodate an schema change in orders. That implies adding a new version number in the URL for v1/orders and v1/customers. Although customers is still the same resource, it’s now referenced as a new resource v1/customers.
It’s hard to introduce backward compatibility changes. You might want to introduce improvements or changes that new clients can use without affecting existing ones. You can create a new version number for this, but it will represent some unnecessary overhead. Existing clients won’t be affected by the change so creating a new version does not seem to be right. Also, you will not want to keep the same version number as you will want clients to know which specific version they are targeting.
It does not go along with the idea of introducing incremental changes. A new version number usually represents a major release. If you want to make those changes public as they become available, you need a new version number. However, you won’t want to create v1, v1.1, v1.2 for the overhead discussed in #2.
Use an http header to specify version. If no http header is specified in the request message, stick to the latest version.
|1 2 3|
The “accepts-version” header represents the version the client can understand. If some changes were introduced in the resource representation that won’t affect the client, the service might be able to return it. Let’s say that you now have a new version 1.3 for /orders, which only contains backward compatibility changes. The server can return a header to inform that.
The client will know a new version exists, which is also compatible with 1.0 so it can optionally upgrade to it. This approach also works for fine for dynamic languages or schema-less types like json.
For embedded URLs or browser support, the http header can be replaced by an optional query string parameter ?accepts-version or ?v to make it shorter.
I thought would be better to show rather explain so there you go http://www.screenr.com/AOD7