I am currently looking at implementing feature toggles using ff4j for our application. We want to have a remote central config app which will hold all the features in it and the applications will talk to this central config app via REST to get the features. We will not be able to leverage Spring Cloud Config or Archaius for this purpose.
I went through the documentation and it seems there is a support for HttpClient (https://github.com/ff4j/ff4j/wiki/Store-Technologies#httpclient). But I couldn't find any sample for the same. Can someone please let me know if I can leverage this method to build my feature store from a REST endpoint. Also, I would appreciate if someone could point me to a sample of this.
This is a common pattern.
A component holds the Administration UI (console) and the REST API. You can call it the "Admin Component". For security reasons It may be the only component to have access to persistance unit (any of the 15 DB implementation available)
For the "admin component" HERE is sample using standAlone spring-bppt application using JDBC DB, and HERE you find a simple web application.
The REST API can be secured using credentials user/password and/or API Key. More information HERE
All microservices access the REST API as clients and request feature store. You will need the dependency ff4j-webapi-jersey2x or ff4j-webapi-jersey1x that hold the client http> Then you can define the store using :
FeatureStoreHttp storeHTT = new FeatureStoreHttp("http://localhost:9998/ff4j");
Warning : Please consider using cache to limit overhead introduce by accessing the REST API at each feature usage. More info on cache HERE
Related
I have created some APIs in API management layer, which are essentially proxies between the calling client and an underlying web api.
I did this by importing the swagger file of the underlying API, and then adding the newly created API to a Product, repeating this for each separate proxy that I needed. This means then that the underlying API could be called but not without the subscriber key of the product that the newly created API was attached to.
Is it possible to do something similar with API apps, i.e. creating API apps using just the swagger file from the underlying API in the azure portal, that act as proxies between the calling client and an underlying web api (as below)?
Do you mind expanding on why do you need to have API Apps acting as proxies?
I am not aware of such capability for API Apps specifically. There are Swagger-based code generation tools available, for example on http://swagger.io/open-source-integrations/. So perhaps you will be able to find something that would work for you.
I am experimenting with Mule API management these days. What I come to know is we can deploy our API to one of these:
A Mule Runtime
An API Gateway
In the documentation, it is said that we should go with option 1 when we want to separate out the implementation of your API from the orchestration. What does it mean?
Can any one please explain in detail?
Policy management from API Platform and analytics generation can be achieved only by using a correctly configured API Gateway, which is a superset of Mule EE (current version is API Gateway 2.1.0 which contains Mule EE 3.7.2).
Depending on your architecture you may have different solutions.
For example:
Proxy running on API Gateway, implementation API running somewhere
else (eg. Mule EE/CE, Tomcat, cobol server, etc)
Proxy and implementation API running on the same API Gateway
Implementation API
managed directly from API Platform without using the autogenerated
proxies.
HTH :-)
Not exactly sure what they mean there, because on this page: https://developer.mulesoft.com/docs/display/current/API+Gateway they also mention this:
Note that the API Gateway, because it acts as an orchestration layer
for services and APIs implemented elsewhere, is technology-agnostic.
You can proxy non-Mule services or APIs of any kind, as long as they
expose HTTP/HTTPS, VM, Jetty, or APIkit Router endpoints. You can also
proxy APIs that you design and build with API Designer and APIkit to
the API Gateway to separate the orchestration from the implementation
of those APIs.
So both methods technically allow you to separate API from orchestration, as your API gateway application could simply proxy another Mule application elsewhere that performs the orchestration. But my understanding of the two options are:
The API gateway is a limited offering that allows you to use a subset of Mule's connectors, transports and modules such as ApiKit and HTTP, it allows you to expose and API then use http to connect to whatever backend systems you want as a proxy and perform the orchestration in the API layer.
By using the Mule runtime operation, it gives you much more flexibility and allows you to compose as many applications as you want using the full range of connectors etc. and separate out the different aspects of your applications into as many layers as you want as separately deployable entities that you can deploy to on-premise standalone instances or Cloudhub etc.
#Ryan answer is more or less on the mark, however if you do choose the Mule ESB offering you will loose out on the API Management and governance functionality that API gateway provides OOTB.
These include
Lets you enforce runtime policies and collect data for analytics
Applies policies to APIs or endpoints around security, throttling,
rate limiting, and more
Extends PingFederate to serve as identity management and OAuth
provider for your APIs
Lets you require or restrict certain behaviors in a few simple steps
Lets you add or remove policies at runtime with no API downtime
Manages access to your API by issuing contract keys
Monitors the API to confirm it is meeting all contract terms
Ensures compliance with service level agreements (SLAs)
In my opinion go with API Gateway/Manager if your API will be consumed my third party developers with whom you might not have too many interactions (think public API's) else Mule ESB should be good.
You should be able to migrate from Mule ESB to API Manager (and vice versa) also easily if you need to, so I do not think you will get locked into your decision
PS: Content copied from here
I am working on one school project, And my task is to make a simple api gateway, which can placed between any of the 3rd party api and the end users, tha gateway can be used for defining usage limits of the api or to do some security analysis, I am totally new to this, I know the basic concept of API gateway, but don't know how do I implement it using JAVA.
Can anyone please give me some starting point where to start implementation of API gateway?
And what are the frameworks I should use and for what purpose?
Thanks,
Nixit Patel
In a nutshell, API gateway exposes public APIs, applies policies (authentication - typically via OAuth, throttling, adherence to the the defined API, caching, etc.) and then (if allowed) optionally applies transformation rules and forwards the call to the backend. Then, when the backend responds, gateway (after optionally applying transformation rules again) forwards the response to the original caller. Plus, there would typically be an API management solution around it providing subscriber portal, user management, analytics, etc.
So basically any web service framework would work as a quick DYI solution.
You can also use plugin model of an open-source load-balancer such as NGINX.
Or take an open-source API Gateway to learn from it - e.g. WSO2 API Manager (the easiest way to see it in action is the hosted version: WSO2 API Cloud)
I wanted to know how to can i protect a resource on a webserver using REST API.Like for example i want to access http://www.xyz.com/folder/impresource.doc but before accessing that i have to be authenticated. The thing is i am try to create a simple mobile client to authenticate with a rest service and then be able to access the resource.
I would appreciate a good example explaining how it can be done Thanks :)
It would be nice if i could get an example in php.
You implement a web service (be it REST, or be it SOAP) in some programming language (for example, Java or C#) running in some "container" (for example, IIS/.Net or Tomcat).
The layer below REST (for example, the C# code you're using to implement your IIS/.Net/SOAP web service, or the Java code in your .war) is the layer where you want to write any custom access code.
Alternatively, some vendors (for example, Amazon S3) have already done this for you:
http://aws.amazon.com/s3/faqs/
Other vendors (such as Microsoft) give you a way to use their authentication infrastructure with your web service:
Secure REST Service Microsoft Azure AppFabric
In java you can use a servlet filter, which will send an error code if it does not find an authentication object in the user session and if authenticated let the request handling proceed. A very popular implementation of this approach is Spring security[http://static.springsource.org/spring-security/site/tutorial.html]
If you have ever used the Flickr API, you'll be familiar with their API Explorer. It is an awesome tool, that allows you to view the documentation for each API method, and the killer feature, being the execution of that API method (with a form to populate any request parameters). It even picks up when you are logged in, and completes the authentication part on your behalf. Gowalla has a similar API Explorer that is also really good.
Are there are tools for WCF that will auto-generate such an API Explorer, free or commercial?
Currently, we use Fiddler to build the JSON requests, but I would like to publish these service contracts, and allow potential developers to play around with them via a web based API explorer.
I am aware of the WCF Web HTTP Service Help Page, which I am using (and is awesome), but it is the API Explorer part that I am interested in.
You may want to look at I/O Docs - an open-sourced interactive documentation system for RESTful web APIs that any API owner can use to deploy for their own documentation. It runs on Node.js and uses Redis as a data store.
https://github.com/mashery/iodocs
Example: developer.klout.com/iodocs, developer.rottentomatoes.com/iodocs
It uses JSON schema based files to define API endpoints, method and parameters. Based on these JSON files, it generates a client interface that developers can use to learn and explore your API. API calls can be executed directly from the documentation interface, producing formatted responses.
It's Open-sourced, so you can be assured of regular updates and improvements. In fact this past weekend, Brandon West from SendGrid (who use I/O docs to power their documentation), created and open sourced the UI to create/edit the JSON schema files for I/O Docs. So you don't have to manually create the JSON files anymore.
https://github.com/brandonmwest/iodoctor
Not exactly what you were looking for, but....
WCF provides something called the WCF Test Client, for this purpose.
If you install Visual Studio, you get it. For example, for VS2008, installed in the usual place, you can find the WCF Test Client (WcfTestClient.exe) in the following location:
C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\
Take a look at Apigee: http://apigee.com/