I need to use multiple APIs from multiple sources in my new website. They are all similar in functionality but with some differences in format. Then I need to build some type of proxy to make them all the same before use.
Can I use an API Management solution like WSO2 to integrate all these APIs and standardize them as a single API?
Is there another solution for this?
Thanks
You are actually looking for an integration solution. Therefore, what suits best is the WSO2 Enterprise Integrator. You can write a couple of Synapse code to combine a set of APIs and expose them as one.
Now, if you need to enforce policies such as authentication, authorization, rate-limiting etc. (i.e. if you need to expose this API as a managed API), then only you need APIM in front of it.
Kloudless provides an abstraction layer via a single unified API to connect to several third-party APIs without having to implement code for each of them. In that way, it functions as a proxy for all those third-party APIs and abstracts out data models, authentication, error-handling and rate-limiting, and more. (I'm a co-founder)
Use Wso2 Enterprise Integrator where You can create API and Apply the various integration patterns to achieve your requirement. Then if you need you can publish the same in API management.
ESB requirement:
You can use either a management console for creating API's or an eclipse designer extension from wso2. For creating API's XML knowledge is enough otherwise it also provides drag and drop feature.You don't require JAVA knowledge as the inbuilt mediators which are shipped with Wso2 ESB is enough. But if you have knowledge of java then you can create custom meditaors(mediators are used for creating busniess logic) incase of some special needs. If you don't know JAVA then you can use Javascript, Ruby, Groovy inside script mediator. I prefer for smaller transformation I will use Script mediator if you have larger message size then you can go with class mediator that's where we'll use JAVA. This is all the requirement you need for ESB.
Technologies required for ESB: XML, XPATH, JsonPath, XSLT, Xquery , scripting knowledge(Javascript, Ruby, Groovy)etc.
If you are beginner then please refer this tutorial https://docs.wso2.com/display/EI640/Integration+Tutorials
For API management programming knowledge not required.
Related
Can anybody tell me where can I see a documentation for the sharepoint rest api ? I would like to see documentation like swagger has e.g. endpoints + dto objects. I need to make an integration with sharepoint to have CRUD functional for files. On Microsoft I see an articls that describe how to use it, but can`t find concrete list with endpoints and data tansfer objects.
Here the official Microsoft documentation : SharePoint REST service,
Please read all the part in the left navigation :
Bonus : Also, if you are a beginner and you want to start with SP API, I recommend you to use SP Insider extention, it is a free SharePoint Discovery tool for Developers. It allows you to explore the endpoint in an intuitive way and build your Query easily.
Cordially.
I have been trying to clarify the definition of API, form my understanding, API is any kind of services that act like middleman when two applications( such as web framework and database ) cannot talk each other directly.
And I think prisma is one of API, am I correcly understanding it?
An API is an Application Programming Interface.
Originally, typically specified how an application invoked functionality in a programming library. Later, the term was generalized to mean other things: for example, specifying how an HTTP-based application must interact with a REST service.
From Wikipedia:
https://en.wikipedia.org/wiki/API
An application programming interface
(API) is a way for two or more computer programs to communicate with
each other. It is a type of software interface, offering a service to
other pieces of software.[1]
To answer your question:
Prisma is an ORM
Prisma has an API. Prisma client apps use the Prisma API to interact with the underlying database.
I am creating an application that needs to obtain information from multiple APIs and I want to create a standard API that allows me to have access to all the others. just changing from a url to direct me to other APIs.enter image description here
It is something like that, in reality there are more than 500 APIs, but it is an application that I treat that consumes almost 100 at the same time, but since there are many servers that are being asked for information, I think it would be more advisable with an API gateway , to control from a single link
From what you have explained, it seems like there are two main use-cases here
Have a single proxy to multiple backend services
Even though only the APIM is enough, the ideal approach here is to have a separate integration layer which is WSO2 EI. Inside WSO2 EI, you can use clone mediator to clone a single request and send it to multiple backends and then when all the requests are completed the aggregate mediator can be used to combine all the responses and send back to the client.
Use dynamic backend URLs
Dynamic Endpoints can be configured on WSO2 APIM and with that approach, APIM has the capability to decide the backend endpoint, on the runtime.
In case, the use-cases which have on your mind are a bit different to what I have explained here, similarly, you can achieve that by a mediation sequence but whether you want to have a separate integration layer or just an APIM layer is enough have to be decided by closely analyzing the use-cases.
Kindly, can anyone differentiate between System api and Process api?
Please provide answer in Generic terms, as i am unable to find on internet.
A system api abstracts from an existing system. It talks to the system in the language of the system (e.g. SOAP, direct Java calls, SAP calls, etc.). To the outside world it offers a clean API (usually REST with http and json). When you do a good job implementing your system api, you can exchange your existing system with a different/new one without changing the api of your system api to the outside world: Just implement a new system api with different adapter logic.
A process api should talk REST on "both ends". It calls one or several system apis to do its job. The process api orchestrates different jobs.
When you need more information, do a search with "api led connectivity"
A System API is a layer you build on top of a system, which handles all system specific connection quirks and settings. It then exposes these resources and it's logic in a standard format (usualy REST but you're free to choose something else like SOAP) to the rest of your API's. Like Roger Butenuth states:
"When you do a good job implementing your system api, you can exchange
your existing system with a different/new one without changing the api
of your system api to the outside world: Just implement a new system
api with different adapter logic."
A process API is where you keep your logic and orchestration, it does not 'talk' to end systems directly but instead connects to system API's to get it's data.
A process API should idealy only talk REST on both sides and can aggegrate data from multiple systems.
An example of a complex process API would be an "items you've ordered" API which takes in a user id as it's input, then talks to the system API of a CRM system to get the id used by the "order history system API".
However this API might only return a list of orders without any article information besides an article id. So our Process API then enriches this list with Article information fetched from "article information system API" with the id from the list.
I know it's out of the scope of the question, but for the sake of completeness i'l shortly explain the third variant as well:
An Experience API can be seen as a doorway into your API network, every (type of) client has different information needs and can communicate in different protocols.
It is the Experience API's responsibility to provide ALL the information required by a client in a format they support.
This takes the responsibility away from a client to know where the information needs to be fetched from.
(Customer info from CRM, Order info from proprietary sys one, Article info from article DB)
This concept of design has as a bonus that if when for example, the mobile app your company is making, gets some new functionality which requires extra data.
You can update the "mobille app experience api", which would leave your "superexpensive IBM Experience api" unchanged. Cutting down on development costs as you don't need to implement any changes in your other api consumers which would be the case had you had only one api.
I think the main difference is where you are implementing business process and rules/logics.
System API, within the scope of your design, are atomic APIs which will be used to construct higher level API (experience APIs). Process API is the orchestration layer where you can use Mulesoft flows to implement business process or logic.
System APIs do the heavy lifting work of CRUD operations.
Process APIs focus on business logic
System API's are underlying all IT designs are center frameworks of records that are regularly not promptly accessible because of its many-sided quality and network concerns. APIs give a method for concealing that many-sided quality from the client while uncovering information and giving downstream protection from any interface changes or legitimization of those frameworks.
Process APIs exemplify the fundamental business forms that cooperate with source and target frameworks or channels through an arrangement of framework APIs. For instance, in a buy arrange process, there is some rationale that is regular crosswise over items, geologies and retail channels that can and ought to be refined into a solitary administration that would then be able to be called.
And you will get some more clarity from this article https://dzone.com/articles/api-the-backbone-of-the-software-industry-know-how
System API and Process API will be part of API led connectivity.
System API is like awrapper service to either a main data base or saas platform
Process API involves application logic to validate search or query parameters
We're working with Cumulocity and we'd like to offer services to our customers that are not currently possible to implement with Cumulocity. As an example, we'd like to be able to retrieve a list of devices located within x kilometers of a given point.
Currently there are two limitations that prevent us from doing so:
the impossibility of extending the Cumulocity API with custom route/parameters
the impossibility of implementing custom functions for specific API GET calls
I can think of a workaround to achieve this, like a POST request of an event that would be processed by an Esper rule, generating another event/measurement that could then be accessed by a GET. But I think we can agree this is not a suitable mechanism.
Please not that the use case I described above is just an example. Our needs don't limit to this and we need a standardized way to expand our services without requirering updates on Cumulocity side.
There are two topics here, I believe:
Geo-querying: Some geographical querying and aggregation use cases can be handled through CEL. A general geo-querying API is on the Cumulocity roadmap. Note: This use case is not only related to extending the API, as such queries go right down into the database.
Extending the API: That is actually possible. Cumulocity has a microservices API in which you can expose other APIs under the URL /services/.... This is, for example, how connectivity platforms are interfaced. The API is not on the web site because it's not GA yet, but you can certainly discuss it with your Cumulocity contact or open a ticket. This btw includes also adding permissions for the new microservices, so that you can do proper A&A.