For our Web api project we use the following url versioning system:
https://{fqdn}/{apiVersion}/{apiResourceName}/{resourcePath}?{parameters}
for instance we can have something like the following:
https://myapi.mysite.com/v1/customer/2
Now considering above, let say you want to release two versions (live,test) to the customer. One live version (working with live data) and the other one is the test (working with test data for customer development test).
For live one I could easily use the one I mentioned : https://myapi.mysite.com/v1/customer/2 .
How do you name the test version of the above api? what is the test version of a api url version v1? Can specify the test api url?
Also what are best practices for fully qualified domain name of the API {fqdn} when using url versioning?
There are really several ways to do this.
One way, for instance, is to simply use attribute routing to give it a different path. Create a separate method, give it a path of /vtest/customer/2 for example and if users access this /vtest/ version (or v2 or 3 or whatever) then return the test data/new version. See an example in this question
Another way is to host your "test data" API in a different application in your server and have your web.config point to test versions of your database/source data. Using IIS, you'd configure two different applications (one for test, other for live) and the base URL would differ e.g.: https://myapi.mysite.com/appname1/v1/customer/2 vs https://myapi.mysite.com/appname2/v1/customer/2 and your appname could be something like live vs test. Have a look at this simple example
You could also just host them in different servers altogether, which would result in your {fqdn} changing between test and live versions (e.g. server.com/v1/customer/2 vs testserver.com/v1/customer/2) - this is what I do at my current job, and I find it very effective as it isolates live/test data (and API versions) avoiding confusion between them.
I also found this blog post detailing how to do this with namespaces
In other words there isn't just one best/correct way to do what you want, it all boils down to how you (or your company/boss/team) wants to structure and control test vs live data in your APIs. Take a look at these options to see which one is best in your case, hope I was able to help.
I think the title of your question is misleading. The problem you are trying to solve is not versioning (because your client is connecting to the same version of your application: v1). It is about having multiple environments: one for live data and one (or more) for test data.
At my company we solve this issue through the host name. At https://live.mysite.com/api/v1 we host v1 of the API connected to live data. At https://nodex.mysite.com/api/v1 we host v1 of the API connected to test data. Our clients can request new nodes as necessary (e.g. client1-devnode.mysite.com/api/v1 to develop against, and client1-testnode.mysite.com/api/v1 to test against. Each node get it's own set of test data.
Most of the live projects different server for different environments.
Instead of using different version of API endpoints, You should use different servers for different environment like this :
For Prod/live : https://myapi.mysite.com/v1/customer/2
For Test : https://myapi.mysitetest.com/v1/customer/2
For Dev : https://myapi.mysitedev.com/v1/customer/2
You need to configure environment specific properties for different backend endpoints you are hitting. Like : test.properties/dev.properties/live.properties
With my experience in API developing i found that there are 2 way of making server (test/developer)/live
I will show an example with your link type
https://{fqdn}/{apiVersion}/{apiResourceName}/{resourcePath}?{parameters}
In your case you can use or settings based and Link based testing type
What is settings based?
Settings based is that your server for example https://rest.mysite.com/v1/customer/2
will acting as test if you or your customer will set in he's settings server status to test and if as live - status to live.
This method is good in some cases but in order to test and to have live in same time,- this type not recommended.
What is link|URL|URI based?
This method have 2 types of identifying request is test or live
One way is to set test as a parameter https://api.mysite.com/test/v1/customer/2 and without test it goes to live
Second way is to set api to testApi or apiTest for example https://testapi.mysite.com/v1/customer/2 or https://apitest.mysite.com/v1/customer/2 . This way customer have both test and live and he can do testing and having live project too.
And don`t forget for security always check customer and verify before giving live api access.
As an option you may use custom defined header. If request contains custom header -> redirect request to test version of API.
Related
I have successfully generated composer rest api followed by instruction given by https://hyperledger.github.io/composer/latest/tutorials/developer-tutorial.html finally am getting success message
Discovering types from business network definition ...
Discovered types from business network definition
Generating schemas for all types in business network definition ...
Generated schemas for all types in business network definition
Adding schemas for all types to Loopback ...
Added schemas for all types to Loopback
Web server listening at: http://localhost:3000
Browse your REST API at http://localhost:3000/explorer
and after am adding participant getting 200 response code in api , but the added data not displayed in composer playground, whats the issue in this? anyhelp appreciated
I think there is a problem with your starting a business-network or upgrading a business-network. please ensure that your started network version same as composer-rest-server API version shown on http://localhost:3000/explorer/. If there is an issue then you can do ./stopFabric.sh. and then start your business-network again.
the playground is exactly what it says, a playground. It's a little environment to help you play with models, test them and create a bna from the result, not to deploy a fully working network.
However, if you do want to see some real data then you have to connect it to an actual network using a proper network card. If you use the web version then that's not connected to anything real.
So, connect the playground to the same network card you used to create the composer rest api and then you will be able to see something.
This being said, the best way to check your data actually exists on the ledger is to use the composer api you used to create you assets.
Every asset endpoint accepts all the verbs you need to work with. You used POST to create an asset, now use the GET method to check the data on the ledger. if you look at the swagger interface, you will see all endpoint, all verbs they accept and the data models required
I am looking for the best way to test this scenario using automation. Before you mention or ask, yes, i have throughly searched to make sure or even get info or knowledge on this topic.
I have a web service that provides various pricing for health insurance. The pricing is based on different class category of race, age, location etc. All that is inputed into the web service to get the fee for the client.
Right now everything is done locally with SoupUI. As you know SoupUI does not have a way for you to randomly change the data in the body, but i need a way to automate this so random age, race, location, etc can be inputed in and verify the result against a CSV file with the information.
Is this possible or is there a better way to test this web service?
-
Per #lloyd request, because he is King here and other known methods i know:
UI Option: We build a UI to interface with the API and use Selenium to run the countless scenarios we have, but they do not want to do this. They are more incline on testing the API itself.
Ruby: Use Ruby to connect to the API, using Rspec and Airborne (https://github.com/brooklynDev/airborne), the downsize of this is also the same as using SoupUI. Everything is entered in manually, and the code just runs through the various variations we have to get the return and match it against what it should be.
I also found another tool, https://assertible.com/ but the downsize of that is we cannot limit the random generator between 2 selected numbers, plus no way to do the comparison.
Then there is Postman, which is also similar to SoupUI so not a real automation since we cannot change the values in the body. http://blog.getpostman.com/2015/09/03/how-to-write-powerful-automated-api-tests-with-postman-newman-and-jenkins/
When creating an instance of REST API (an application), a version (appearing as a prefix) has then to be included in the URL when calling it.
Is there a way to manager several versions (at the same time) of an API? Are we able to change the version number or how is it changed?
The only link I have found is : https://docs.marklogic.com/guide/rest-dev/intro#id_64988
But it is not pretty clear to me.
Thank you for your help
As the link says, "The version number is only updated when resource addresses and/or parameters have changed. It is not updated when resource addresses and/or parameters are added or removed."
In other words, the REST API will increment the version step if it ever becomes necessary to rename or restructure the addresses of resources. Ideally, that will never need to happen. If incrementing becomes necessary, the goal will be to maintain a deprecated interface if possible at the old address for one release.
In addition to David's good suggestion, you could also build your own version numbers into the name of the resource service extension if it's better to support multiple versions of an extension in a single modules database.
If this is to have versions of your rest extensions and use the V# in that process, then I think you could have multiple sets of your code deployed in different modules databases (per version) and dynamically switch modules database based on the version and then rewrite the URL after that to play well with MarkLogic's REST API.
http://developer.marklogic.com/features/enhanced-http
I'm trying to build an API which can be used to update some master data in my app. It contains various drop-downs for city, country etc. Whenever I add new data in these drop-downs, I need the apps to hit this API once a day and get the latest data. Also, if the API is requested older data (from older apps), it should be able to return such data based on some date query parameter.
What's the best way to create such an API?
Also, the API needs to be RESTful and will be exposed to Android/iOS environments.
API should be able to return so based on some date query parameter.
You can use two columns created_at and updated_at in you tables schema. So how can this will useful for your situation:
Whenever some one hitting api without date parameter, you are return all data which are created before current time.
Whenever some one hitting api with date parameter then you can return data which are created before value of date parameter.
Obviously you have to write complete logic for this at server side
end.
Please explore one of the Mobile Backend as a Service (mBaaS) products for your long term needs.
Here are some players:
BaasBox: Open source backend
Backendless: Allows
developers to have an instant backend without writing server-side
code.
Apigee App Services: provides a lot of free storage, push notification, analytics etc.
Appcelerator: An BaaS targeted at the Enterprise audience.
For the short run you may want to try https://www.webscript.io/ to embed some quick javascript code to return the JSON response for you.
I would put a spin on #Santanu's suggestion of using BaaS. I would recommend using a BaaS during the development phase of your project.
When the iPhone and Android Apps have been developed and tested, replace the Baas-based server components with a in-house built RESTful server.
This approach has a couple of benefits. It lets you divide the effort into two distinct parts: the client changes to your product, and the building of your server component.
I assume your company's current expertise lies in App development, so it should be easier for you all to upgrade your applications to use the BaaS-based APIs.
It will also be much easier to reiterate and refine your data components and models using a mature BaaS server.
With Apps using data requests to populate the drop-downs from a BaaS-based RESTful API, and stable working data models and data sets hosted in the BaaS servers, it will be much faster to start building your own RESTful service.
When you run into issues, you will be confident they are in the server side code. You can run A/B tests with the same Apps against two versions of the server and ensure the client experience is the same.
You could continue to use the BaaS Server for rapid prototyping and developing API extensions.
Can someone please point me to the right direction.
I need to be able to host my GWT application in a way that it allows multiple clients to use the same application which could be separated by url's but internally using the same application.
the different sites would probably be seperated by different configurations. eg. different database, different log path etc, etc,
any ideas.?
You could use the following way to arrange your projects :
- my.application.core.project : it holds all the business logic and views for the application except for the entry point
-my.application.customerX.project : it holds only the entry point and the property files used for having the connection to the db, probably customerX specific theme
-my.application.customerY.project : it holds only the entry point and the property files used for having the connection to the db, probably customerY specific theme
Such an organization of the projects would allow you to have a common core that is distributed to each of the customers and also the ability to build on top of the core customer-specific impelementations.
The url's per client can be done with URL rewriting. Be it with an apache server in front of your application and/or in combination with a Filter in your web application.
As for the configuration, logging, and/or database per client you want a solution that doesn't store a file per client on the file system next to your application. Preferable you store client specific settings in one database and have an admin interface to manage it. For the client's data you also don't want a separate database per client, because it doesn't scale well, and would be a maintenance mess if you need to upgrade your application and databases to a newer version. Look for a multitenant architecture.
I admit this is a vague answer, but without specific system and software descriptions it's kind of hard to give a concrete answer. Nevertheless I hope this answer does give you some direction.
I have successfully achieved this by setting up separate directories in tomcat for different clients and then creating soft-links to the main application within that folder. when it comes to database connection properties and other configuration properties, instead of pointing them to the main application I just created them separately.