I need to create a mechanism to request the latest version of my API. I know that you can specify a default version, but I don't need this. The purpose is to access to https://<server>:<port>/api/latest/<controller>, where latest is actually the most recent version. I need to define both versioning options: the major/minor and this one. Below are the two different ways to perform requests:
https://<server>:<port>/api/latest/<controller>
https://<server>:<port>/api/v1/<controller>
https://<server>:<port>/api/v1/<controller>
In the above example, the latest would point to the v2.
The difficulty here is that the built-in ApiVersioning from ASP.Net Core (the Microsoft.AspNetCore.Mvc package) doesn't support string named versions since the ApiVersion uses integers for versioning.
Is there any "clean way" to achieve it?
Related
I've written a small application which accesses the REST API of Atlassian Bamboo.
As the documentation describes:
To get the latest version of the API, you can also use the latest key-word.
So I used the latest keyword to access the version. But I noticed now, after migrating to the new Bamboo version, that this wasn't the best solution, because the new version seems to have changed some things in the API and breaks my application.
Now I would like to build my application with a specific API version. But how can I tell: which is the exact version of the current API?
The only thing which the documentation is saying about this:
The API version is independent of the Bamboo release number.
The API version may, or may not, change with a new Bamboo release. The API version number will change only when the updates to the API break the API contract, requiring changes in the code which uses the API. ...
The documentation of the single Bamboo versions (like the one for 6.6.2) only uses the latest keyword as reference.
And even the REST api itself (under /rest/api/latest/info) only tells me the Bamboo version, not the API version:
<info>
<version>6.6.2</version>
<edition/>
<buildDate>2018-08-14T09:01:47.000+02:00</buildDate>
<buildNumber>60606</buildNumber>
<state>RUNNING</state>
</info>
So how do I find the exact API version of my Bamboo installation?
Two part question:
How does one get the currently installed version of Realm in code? Swift 3, macOS. I was unable to location any Realm.version property - perhaps I overlooked it.
In a related question
What is the solution to upgrade Realm to the latest version within a project? After updating CocoaPods to the latest, and refreshing, pod install doesn't appear to update Realm. I have 2.0.3 installed and 2.2.0 is available.
If you're embedding Realm Swift as a dynamic framework directly, the version number is contained in the framework's info.plist file. It should be possible to access the plist during runtime; there's a few answers on SO discussing this.
Since CocoaPods creates dynamic frameworks for Swift, the above approach of accessing the info plists should work, but if it doesn't there might be other ways to access versions of pods.
In any case, I would definitely recommend you review why you're wanting to check the version numbers of your libraries. It's better practice to check a framework's capabilities at runtime (eg, testing a class you need exists etc) than to directly use the version number.
For your second question, you need to run pod update RealmSwift to get CocoaPods to check for an updated version of Realm.
I'm wondering if the Azure Notification Hubs REST API documentation is still correct and up-to-date or if there is already a newer API version than "2013-08" that can be used.
All the single pages show "Updated: February 26, 2015", but I guess it was just a meta data update of all the pages, since the API version didn't change, it's still "2013-08".
Here (and here) is an example for the REST API usage from Elio Damaggio which uses "2013-10" as the api version.
I tried all possible api version values in the format "yyyy-mm" from "2013-10" to "2015-03" and the following were working: "2013-10", "2014-01", "2014-05", "2014-08", "2014-09", "2015-01".
Does anyone use a newer API version than "2013-08" or does anyone know anything about a newer API version or documentation? Specifically, does anyone know if there is a documentation for a newer API version, e.g. "2015-01", or at least a changelog?
Got an answer on MSDN forums:
The latest version is 2015-01. All or most of features works with
starting version 2013-08.
Version in documentation indicates that minimum version required for
working that feature. Hence, all documentation is pointing to 2013-08.
...
Yes, you can use version 2015-01 instead of 2013-08. There won’t be
any difference because we didn’t do any breaking changes from 2013-08.
All the features works from version 2013-08.
Moreover, the source code for the Java REST wrapper for Windows Azure Notification Hubs on github seems to be a good reference. It is using api version "2014-09", not "2015-01" right now, but at least it includes the registration code for Amazon Device Messaging and Baidu Cloud Push which are currently missing in the REST API documentation.
I am working on Web Api with OData enabled. I started working by referring to (only the relevant dlls to the question are mentioned)
Microsoft.AspNet.WebApi.OData
Microsoft.Data.OData
Microsoft.Data.Edm
System.Spatial
But when I found out OData is by default case-sensitive, I look for a solution of case insensitive and I have gone through few post Support OData Uri case insensitive parse & ODataLib 6.7.0 Release then finally landed into nuget package Microsoft.OData.Core 6.9.0 which seems to be solving my problem. Here my confusion starts, It has its own collection related libraries under different namespace
Microsoft.OData.Core-----------VS------Microsoft.Data.OData
Microsoft.OData.Edm------------VS------Microsoft.Data.Edm
Microsoft.Spatial--------------VS------System.Spatial
What is difference between above similar libraries, where we should use one upon another? In similar cases of mine, Microsoft.OData.Core can be use instead of Microsoft.Data.OData which is solving case sensitive issue?
1. About the namespace,
Microsoft.Data.OData
Microsoft.Data.Edm
System.Spatial
are the implementation of OData Version 3.0 Spec. The package name on Nuget end with OData v1-3. For example: ODataLib for OData v1-3
While,
Microsoft.OData.Core
Microsoft.OData.Edm
Microsoft.Spatial
are the implementation of OData Version 4.0 Spec. The package name on Nuget don't contain version . For example: ODataLib
2. About the case-insensitive
Web API OData will support case-insensitive, unqualified function/action call and Enum prefix free in the 5.4 release.
Here's a simple example you can refer to.
The source codes are moved to:
WebAPI OData on Github
And you can get the binary from nightly build.
Where can I find information about upgrading Magento Enterprise 1.7. to the latest 1.9. ?
There's no such documentation.
Your general approach:
1. Close production server
2. Backup all DBs and Magento installation
3. Turn off all your custom extensions and themes
4. Delete from HDD: core Magento modules, their layouts, all standard themes and cache.
5. Get 1.9 EE, copy it over your installation
6. Request Magento through http
7. Walk at your site, notice errors and warnings, fix them
8. Check documentation and update for your theme, whether it supports EE 1.9. Turn it on if it supports, otherwise you'll need another theme.
9. Check documentation and updates for all your custom extensions - whether they support 1.9. Turn them on - one by one.
You won't have any problem with upgrading all core DB data - it's made automatically.
You'll have problems with your custom theme, as you'll need new version with support for 1.9. And you'll need to check your custom extensions and upgrade their source and DB data to fit 1.9.
Generally all Magento upgrades work by running the updated code with the old database. The differences will be detected and incorporated automatically on the next page request. Magento keeps track of every module's version number for this reason.
Because there is a chance some modification will break it is best to do this on a new (temporary) site then add the modifications back in gradually. That way the old site is still active and uninterrupted.
I think there is no official documentation. The best way is to figure out what core functionality is used in your customizations and after that look at theirs realization in new version: does it changed or not.
To know what was changed in new version you could check changeslist