I have a logistical question: I'm trying to figure out the best way to manage APIs getting out of sync with an app. The best way to explain it is with an example:
Let's say MyApp Version 1.0 posts to a "submit_feedbacK" API that requires first_name, last_name, and email.
I then submit MyApp Version 2.0 to the App Store. That version is designed to post first_name, last_name, gender, and email to the API. All of these are required fields on the API.
The problem I have:
- If I update the API before the new App is live, it will break Version 1.0
- If I wait until Version 2.0 is live and remotely cripple 1.0, I have to time it correctly.
I'm going to guess that the 'right answer' is to maintain two different APIs. But if both APIs post to the same live database, that makes things a bit awkward.
Does anyone have suggestions on how to model this?
This question may share some aspects with iOS consuming API design.
The right answer is definately to provide two APIs (at least for a short period of time while users adjust). You do not have to maintain two versions at the same time, as once a newer version is released you can maintain that one, and simply provide the old one for legacy users. The only real changes you may have to make to it are things like security patches or major issues. Major changes (such as you deciding to restructure your entire database) may lead to the old version not working any more, however update to newer API versions should be designed to allow previous versions to still function.
The other question I linked you to gives an answer about how you can have different version of your app access the correct version of the API.
Another note is that it may be easier for you (depending on what framework you're using) to design your APIs as engines or subapps, and simply mount them at different end points. I know that this is easily do-able in Rails by using Engines, and in Node with Express using app.use() with sub-applications.
I would use a webservice/http endpoint for the communcation with your app. If you preferer to maintain the same URL in all versions of the app, then include a version number in all the requests/posts to the server so it knows how to handle them. This will also make the development and tests easier as new versions can test against the new api on the server.
So on any function you can call in the webservice/server add a single variable with version number. a BYTE ought to be enough as I think you could start over and "kill support for v1.0" once you hit 256 versions of the same function (if ever).
Once the server receives a request/post with data, you can just code a simple switch/case structure in the server API so support works for both versions.
If they do similar, but eg. swaps the parametres or something, you can handle all these serverside and the BAL/DAL (n-tier structure) can be maintained on the server part of the solution.
Btw. my answer is not just for iOS or smartdevices, but merly a client/server approach for a "work-in-progress" production setup where everything has to be online, while still being under development and maintanance.
Hope it makes sense, otherwise, comment on it and I shall try to explain it further.
just FYI, I use CodeIgniter. I'm using the REST Controller provided at https://github.com/philsturgeon/codeigniter-restserver. I ultimated ended up settling on having different end-points for every version. Basically I'd check out a new repository for each release and put it into a unique directory. (i.e. http://www.mysite.com/1.0/api/method, http://www.mysite.com/1.1/api/method, etc) Trying to maintain multiple versions of an API under one code-base just sounded too scary. At least when I released a version, I would know it is locked in stone and I don't have to worry about breaking it. (Note: I had to use a special .htaccess tweak to get multiple CodeIgniter instances running from the same domain. I can share it if you like)
Related
Ive been making API's for about a year now and I was taught to use http://IPAddress:Port/api/v1 all the time when building an API with express.js. Is there a specific reason I would want to do that? Is this just denoting that the API is in development? Ive recently changed my API to not run on port 3000 so that I am able to just say http://IPAddress.com/ instead of http://IPAddress.com:3000/api/v1 and it works just fine the new way.
One main reason for versioning an API is because it may be that an API can be improved upon but doing so might lead to breaking changes (for example, it might not work for applications that are consuming the API because an endpoint has been modified).
So, the solution to this is to allow consumers of the current API (v1) to keep using it until they want to switch, and release an updated version (v2) for new consumers.
Here's some more info on it: https://restfulapi.net/versioning/
I'm trying to confirm all the calls we currently make are supported in Gooddata's java sdk (https://github.com/gooddata/gooddata-java/) before we decide whether to update to use this.
I have confirmed all cases except 2 and am hoping that someone might be able to suggest how I might make these calls in the java SDK today.
list all users in a domain: (https://help.gooddata.com/display/API/API+Reference#/reference/users/manage-users-in-a-domain/list-all-users-in-a-domain)
assign a userfilter to a user (https://help.gooddata.com/display/API/API+Reference#/reference/data-and-object-permissions/assign-a-data-permission-to-a-user/assign-a-data-permission-to-a-user)
I just want to confirm these operations are not currently supported before I investigate effort to add them.
As far as I know, you are right and there is no built in support for GoodData domain (also called organisation) user handling (yet). On the other hand using "com.gooddata.sdk.service.httpcomponents" you can easily work with any GoodData API within your code.
In case you wouldn't be tied to strictly to Java - there is possibility to use bit more robust "Ruby SDK" - https://sdk.gooddata.com/gooddata-ruby-doc/docs/getting_started.html which natively contains user management
Another possibility is to shoot feature request directly into the repository (https://github.com/gooddata/gooddata-java/issues) - we will check that up and most likely add the support soon (or at least give you the estimate).
I'm using SAP Success factors API that i found:
I'm sending get request to this host https://user_name.successfactors.eu/sfapi/v1/soap12?wsdl with relevant credentials and i'm getting an XML but without the user version (something like b1808 (for august 2018).
Do you know how can i get this version?
Thanks a lot:)
First of all, SFAPI is deprecated or will be deprecated soon and I personally expect SFAPI to reach "end of life" within the next releases. But that is my personal opinion, officially SAP recommends using OData API but does not restrict using SFAPI: Page 8/9 for Deprecation Info
I am quite familiar with OData API and did not find any version information, I assume this also applies to SFAPI. The assumption relies on the information, that the APIs are always downward-compatible, this means you don't have to develop for a separate version, you could developt against the API no matter of the underlying version of the system.
If you really require to split according to the version of your system you could only separate by your system. This means if you have a two-tier environment, you need to know where you are requesting the API and develop against it. Furthermore systems differ from 3 to 8 weeks, 4 times in a year, but still they are compatible.
Maybe you could describe your goal a little bit in detail, then I might help to find a good solution.
I am planning to use node webkit for porting my existing html/css/javascript from a web app to desktop native app.Before doing this, i was trying to see if there are any downsides of using node webkit.
Which is the best database supported by nodewkit
My understanding is that it does not require any browser to run this node webkit app and that it provides webkit engine and the app provides a UI to it by using html5, and css.Is this understanding of mine correct?
All your pointers will be helpful.
Thanks!!!
Yes that is correct. Node webkit works as an HTML5/Node.js application wrapped around simple browser app written on Chromium Engine, and it doesn't need anything installed to work.
As far as I understand You want to connect to remote database, not create a local one for user data. If that's true, You shouldn't implement it on client side, but on server side. Which means your server side implementation shouldn't differ from Your actual one.
I create some applications with the following struct :
- folder : server (for any php/db request or response)
- folder : client (for js/css and images)
the relation beetween the client and the server is AJAX.
and the best db for a local use I prefer : Sqlite (in a network MongoDB or MySQL)
in all the cases it's preferably to use an ORM like Doctrine.
and make sure that in the response of server you send allways a json (not a formatted divs or any html) the client must be able to organise his data him self.
as a sample : openerp use this structure (with python istead of php).
for use of sqlite here is link that explane the way:
http://tejasrpatel.wordpress.com/2011/12/29/create-sqlite-off-line-database-and-insertupdatedeletedrop-operations-in-sqlite-using-jquery-html5-inputs/
that's the advices from my experience. and hope this be helpfull for someone.
I am currently developing a node-webkit app myself as well. I had this same question so as I was looking around I found PouchDB. This looks very promising for a node-webkit environment so that's what I'm going to be using. I hope this helps you out as well.
Actually there is one major part of node-webkit that you don't mention in your question, that is the 'node' part, specifically node.js. This is important because just about anything you can do in node.js is available to you in node-webkit.
I don't know what your application does, so I can't tell for sure, but you may or may not need an actual database. If all you want to do is store some data, you may find a file to be sufficient (JSON or whatever format is convenient for your purpose) which is easy to do with the fs module. Or you might only need to use localStorage, which is also available in the 'webkit' part of node-webkit.
If you do actually need a database, then anything works with node.js should be available to you, such as the aforementioned pouchdb, or any number of other possibilities.
In any case, you don't need to set it up as a client server model if you don't want to, you can just access files or databases directly in your node.js code. Conversely, if you do want to do a client-server model, you can have both running locally within your node-webkit program.
Hope that helps.
I use node-webkit insted of Qt, PySide, etc. and I tell you why:
webkit (the most full feature browser)
nodejs (what can I say is javascript)
cross platform (almost all)
To package and distribuite the software I use Web2Executable
For the GUI I use ExtJs 4.2 from Sencha
Database (engine) I use NeDB but you can use internal engines from webkit found here persistent-data-in-app
Overview:
We have a rails REST API app that's gonna be published soon together with client app (single page app written in JS) . We intent to deploy new stuff on almost daily basis. For now the API is only used by us internally.
Questions:
How to manage deployment because we deploy each app separately?
Should we always deploy them together? Should we raise API version for each deployed change?
How to reload JS app when new version of API is available?
Should we not change the API version but keep backwards compatibility in mind? So only add new keys in JSON responses, no renaming, no deletions, no changing of URLs, ...
Are there any best practices described somewhere about this particular problem?
It is considered a best practice to only version a RESTful API when making a breaking change.
I would strongly suggest not releasing the API to the public until it has stabilized more. As long as it is internal-facing only, the frequent changes won't be as big of a deal. Once your API goes public, you'll want to limit the number of breaking changes (new versions) as much as possible, so work with your best customers before your public release to make sure the API is adequate, and try to design it with backwards compatibility in mind.
You should only need to pair the releases if there's a breaking change on the API side. Pairing them or not may be a business decision ("It's easier for our customers to have one version number to worry about than two").
You might also consider resetting the version number at release time so that the public is given the stable API at version 1 instead of 18.