I currently developing a multi tenant saas application using asp web api. The api will be published and consumed by 3rd party application. My question is regarding versioning. I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api. I also have to update the old api to adapt to database change. That seems like a lot of work. How do big companies solve this problem?
There is no easy way around this; you will have to do the work to support old versions as long as your customers are using them.
Adopting a RESTful approach in the first place, and avoiding 'fat controllers' may help reduce the pain but beyond that every old API call will need to call into your new service layer and will need to return the results in the format your clients expect.
I'm struggling to find a way to build the api so that when i updated the api, it wont make 3rd party app that uses the api to stop working. I've seen many api append the version no into the url. But that means that i have to keep old version api until all 3rd party app has been upgraded and use the latest api.
No one, absolutely no one has researched, built, versioned and maintained APIs more than NetFlix - not externally but internally. They used explicit versioning (e.g. URL) in their APIs and maintained multiple versions of the same API and got their clients move along by providing incentives (new features). This is also something that can be built into your SLA, e.g. you guarantee support of particular version only for 12 months.
This is a very controversial topic and you will hear people suggesting implicit versioning (e.g. by media type etc). Feel free to listen to those but pragmatism favours explicit and purism favours implicit.
Related
Apologies in advance for the seemingly naive question, I'm a hobbyist developer learning the ropes. I noticed the opentok REST API documentation deal mainly with command line stuff, whereas the SDKs (web/node SDKs for example) come packaged with class instances, methods, etc. So is one a reference for the other? How/when does one use the REST API instead of the SDKs?
Vonage Developer Advocate here.
Our server SDKs provide a language specific wrapper for our REST API. Both are focused on session & token generation and archiving. This logic is usually processed on the server side.
The client SDKs are different in that they provide capabilities for the front-end.
I want to build a real-time data API using SignalR on the server. I will be building a web client that will connect with the API the "usual way".
However, I would like 3rd parties to also be able to connect to this API. These clients may be web clients or other platforms such as Windows, Mac, iOS, etc. Ideally, they'd just be able to connect via plain websockets and be totally agnostic of whether SignalR is in use on the server or not.
It seems that there are a lot of libraries out there for clients on different platforms (Swift, Objective-C, Java/Android, c++, etc) that would allow them to connect to my API. Another approach (that some of these libraries use) is to embed a hidden web view. Either way it's quite a bit to impose on the 3rd parties. It needs to be simpler.
Is there a way to write a web application (for example) that only uses standard websocket calls and talks directly to my SignalR server without needing to include any SignalR specific scripts as dependencies? Can a non-web client do the same (i.e. make standard websocket calls, with no embedded web view)?
Basically, I would like the effort 3rd parties need to go through to be no greater than if I decide to make a vanilla websocket API and avoid signalR entirely.
No. You can´t do that currently. But that will be possible in the next version of SignalR (Asp.NET Core Sockets) according to this video. The first beta release is planned for mid 2017.
UPDATE
It seams that it´s indeed possible with some workarounds. Take a look at this link.
I'm using Parse.com SDK services for my Android app.
I've seen that Parse had released their Android SDK as an open source project on Github on this address.
My app is almost finished, and when I'm uploading it to the Play Store, I don't want to be controlled by Parse.com (I mean that I don't want to be blocked someday, or I don't know that), so I want to move my whole database to my own server that hosted on a secure company.
I've checked the open source project on Github and realized that all I need to use it on my own server is to generate an Application ID and a client key.
So I want to ask if someone knows how to generate an Application ID and a client key of Parse to use it on my own server, or that you maybe knows another way of moving it to my server? And one more question: Today I'm using also Facebook SDK with my app. If I will move my database to my own server, will I still be able to use Facebook SDK on my app?
Thanks!
I have write an article about how to migrate parse to a custom server.
https://medium.com/#jcminarro/run-parse-server-on-your-own-server-using-digitalocean-b2a7d66e1205
There's a massive difference between Parse open-sourcing their SDKs compared to revealing their entire backend architecture and its configuration.
The open-sourced SDKs are essentially wrappers for Parse's REST API along with some convenience functions and logic for natively interpreting the JSON data Parse is transmitting.
At a high level, Parse uses MongoDB for its core database and is entirely hosted using AWS (Amazon Web Services). The entire architecture is highly complex and is not something you could just drag and drop onto your own software stack or hardware backend.
To help give you a better idea of how Parse achieves all of their services, here's an interesting presentation their Dev Ops team gave at an AWS convention. Suffice it to say, hosting the backend services for over 180,000 apps requires a complex infrastructure and that is the "secret sauce" so to speak for Parse and is why Facebook purchased them for over $85 million two years ago.
I have read about new Google Apps Marketplace and have seen the overview video here.
I'm worried about migration from OAuth1 to OAuth2 and having impact to some developed applications with APIs in my domaine
in the video exactely in 24', comparaison of what libraries/APIs are used in the OAuth1 vs OAuth2, and in 27' talking about turning off the OAuth1.
these Libraries/API will be deprecated ?
Any idea about turning off the OAuth1 and when ?
You need not worry about the impact of OAuth1 to OAuth2. This transition can be completed in a max of 15 days if you have done many integrations with Google. If you are worried just about the SSO with OAuth2 this can be completed in a day as Google has already provided proper documentation regarding the work flow.
Google has even provided migration APIs to upgrade your customers domains from v1 to v2 of Google Apps Marketplace(GAM). If you have a huge user base to be migrated then you need to plan accordingly such that migrated and non-migrated users would be able to use your app for some days till the migration is completed successfully.
Google will announce if it intends to discontinue or make backwards incompatible changes to this API or Service. Google will use commercially reasonable efforts to continue to operate those Google Documents List API versions and features identified at http://developers.google.com/google-apps/documents-list/documents-list-api-list without these changes until April 20, 2015, unless (as Google determines in its reasonable good faith judgment):
So on a safe side it is better to migrate all of your APIs to the latest libraries to avoid any failures at a later point of time. Anyway the older versions are not supported for any issue fixes/ support from Google side. So it is always better to migrate your APIs
Older version of GAM(v1) will also be deprecated at some time but Google hasn't provided any timeline for this. Probably it may take a year(not sure)
Google strongly encourages you to migrate your marketplace application to OAuth2 as soon as possible. Google has already announced deprecation of OAuth1. All top apps on marketplace have migrated their customers to OAuth2 with no issues. We plan to stop allowing installs of OAuth1 applications in near future from the marketplace (specific timelines to be communicated separately).
Good morning,
I am going to write a web service and I am not sure which framework would suit the situation best. I understand what Node and .Net are good at.
The client will call the services at the following stages:
App loads up - user logins in via Facebook API.
User can create an "entity". This entity will be stored in a database (SQL for .Net/ Azure table for Node) and also posted to a Facebook application (timeline stuff). User can make changes to this at any time.
User can browse Facebook Friends (Facebook API again).
Changes to the entity will be pushed to all users who have "joined" the same entity (SignalR .net/Socket.io Node).
That is the skeleton of the web services, there may be more Facebook calls or CRUD operations. Which Framework will handle this best?
Many thanks.
Aside from the mentioned WebAPI, also consider the excellent ServiceStack for building a webservice.
Any well-written code regardless of the framework will be able to handle it.
If you are a .NET developer I personally think type safety of C# is important so I would not go down the Azure node.js way since it will also force me to use Azure.
I would personally use ASP.NET Web API.
As long as you build your application on a solid framework, you'll be on the bright side (assuming you know how to set-up such an application in a secure and proper manner). For .NET i'd use the Web API and for node.js i'd stick with something like express/connect.
Just keep in mind that node.js and the frameworks based on it are still subject to heavy changes, whereas ASP.NET is production-safe since years.
As a bottom line, i don't think you're able to say "X is better than Y because of Z" in this scenario. It's a matter of personal preferences, infrastructure and your technical skills.