To get started quickly with API Connect, I just want to import a Swagger spec of an existing service and make this service a managed API in API Connect.
API Connect provides an import function for YAML files, but the API can not be tested.
I've seen this scenario several times, so I though it might be useful to have some documentation on this.
When importing a swagger specification, you need to modify a few settings to transform this service definition into an API definition (even though they are quite similar). You need to modify the following parameters:
Schemes https - The Gateway enforces HTTPS
Host: $(catalog.host) - This variable links to the current host (in a certain catalog)
Then, you need to build an assembly. The proxy policy is well suited for building facades, as all content from Headers, Body, etc. is re-routed. For the URL, enter the URL of the endpoint + a context variable that refers to the incoming path, like:
http://example.com$(request.path)
I have created a small video on Youtube to demonstrate the neccessary steps.
Related
i am taking a course in web data so i understand that when we want to retrive a webpage on a browser we do a request response cycle using a communication protocol like http or https and a web service is a piece of software which i dont know where it is stored or how it is accessed so we can make two applications from different architectures communicate using a serialization language like XML or JSON i dont know what is the difference between a web service and http they are both a way to connect 2 different computers together and what confused me the more is api which according to the research i did is something used to access web services.
Let's begin with defining all the terms in your question since it's a bit all over the place.
HTTP (Hypertext-Transport Protocol): Allows you to transfer data over the web. Your browser will perform a request using HTTP to your web service.
Service: Any software that performs a specific task. We are interested in a web service, which is typically invoked via HTTP, however this can be anything else such as a Linux signal.
For now, let's assume it listens on HTTP.
API (Application Programming Interface): An interface by which all clients of your software have to abide by to use it. For example, in our web service, we can dictate an API so requests follow some convention.
Let's put it all together now.
You're making a website that wants to calculate the sum of two numbers. First, users will go to http://yoursite.com, and then the browser will always do an HTTP request to the domain yoursite.com on port 80. This will hit either your hosting site or some backend server.
Here you have the option if you're using something like GitHub pages to serve static content or you have some server (i.e., serverd) that will load a file and serve it.
So now the web-browser did an HTTP request and your webpage should load with an index.html. The user can now click on buttons, and everything looks good until they press Calculate -- what happens now?
We want to offload the computation to our backend. We perform an HTTP request to our backend server. We can define an API, that is in our case an endpoint, so that the HTTP request can hit it and it'll return the sum of the two numbers.
How do we return the result? We need to represent the data somehow, and this can be done through a body payload that is encoded as either JSON or XML. Again, this is a serialization format and can encode it in various different ways. JSON is nice because you can parse it easily with JavaScript on the client side.
Great -- so now we got an entire site and it works! Now we can do an HTTP request from our browser straight to the backend according to our setup endpoint and it should fulfill our request. Notice how now we're using the API from the backend server from within our site.
Other keywords you can may run into: CORS, AJAX, Apache Server; good luck!
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
I am using serverless framework to build a REST API. I have reached the 200 limit stack size and read about the multiple approaches to circumvent it. The most common approach is to split the stacks in a "microservices fashion", where each stack handles a particular set of resources that make sense together.
Because of how serverless works each of those services would create a new api gateway for itself and then, as explained in this blog post, a shared domain can be setup between them so all endpoints can be accessed through the same base url.
Even though this is a valid solution I would really like to be able to work with a single API gateway resource shared between the different stacks, so I don't have to decide upfront a separation of concerns between the different components of my api. Is this possible?
This feature has been recently added to serverless. Documentation is available here.
Essentially the apiGateway to be used in a serverless file can be configured through a config option inside "providers".
provider:
...
apiGateway:
restApiId: xxxxxxxxxx # REST API resource ID. Default is generated by the framework
restApiRootResourceId: xxxxxxxxxx # Root resource, represent as / path
This feature was introduced by this pull request and is available from serverless version 1.26.
I'm new to this api documentation era.
Vising this api documentation, I get to post and query data. I understand that's a demo api documentation with swagger.
But what happens with real world API documentation? do I have a documentation in demo.api.myawesome.com and actual api on api.myawesome. com using different data stores?
But again digging deeper, I got to find out that an api can be self documenting using swagger libraries. This seems like both api and documentation are using the same data store which can't be the case.
What am I missing here?
From the Swagger website:
Swagger is a set of rules (in other words, a specification) for a format describing REST APIs. The format is both machine-readable and human-readable. As a result, it can be used to share documentation among product managers, testers and developers, but can also be used by various tools to automate API-related processes.
So yes, it uses the same "back end" as the actual API. It's just visualizing it, allowing you to interact with it via the Swagger UI.
If you mean Swagger UI - the "try it out" button sends requests to the server specified by the host property in your spec. If host specifies your production server, requests will be sent to production; if it points to a sandbox, "try it out" will use the sandbox. You may have a version of the spec for internal use that points to production, and a public version that points to sandbox.
Note that Swagger supports authentication as a way to ensure that only authorized users (e.g. your actual customers with valid credentials or API keys) can make API calls.
You can omit host from the spec to disable the "try it out" functionality - this way you can still have the API docs, just without the interactive part.
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.