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.
Related
We have exposed some new API’s from SAP Commerce and need to get/post data in some of the components or services.
Are there any pre-defined mechanisms to leverage new API integrations, or should we simply use HttpClient from Angular?
We are expecting that there should be a way to get data from new API’s like we have for OOTB API’s such as “StoreFinderService” which helps us to get data for store and there are some other services as well.
Spartacus is using NgRx to handle all API’s and then these services supply data from stores. Similarly, there must be a way to get data for new API’s created as per business requirements.
Spartacus uses the Angular HttpClient under the hood, it's the recommended service to interact with http. However, using HttpClient directly from a component is generally considered a bad practice. You'd better separate concerns, and delegate interacting with the backend to a service.
Spartacus offers an extensive architecture to handle backend APIs, you can read more about it at https://sap.github.io/spartacus-docs/connecting-to-other-systems. You could follow this architecture, but for a project it's overcomplicated. The architecture really targets extension points, which is fair for a product, but most often not for a project.
https://github.com/SAP/spartacus-bootcamp/tree/master/src/app/features/state shows you some examples of introducing a custom state to the Spartacus state.
For projects introducing new features, I would either create and maintain state in a service, or introduce a custom state in ngrx. For the later, you can evaluate https://github.com/SAP/spartacus-bootcamp/tree/master/src/app/features/state that shows how to add new state into Spartacus, or read up on ngrx resources.
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.
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
I am working on a project in MVC that has mobile application so one thing is clear that we have to use Web API so it can used in mobile application.
After creating API when we started to develop Web site we are confused and had discussion on whether to use API or directly access to the Business object. And we ended up after having opinion form more experienced developer to consume Web API instead of using Business object directly.
I'm having confusion regarding to this solution structure.
1) Why we should use Web API and make HTTP request (which is time consuming) to get or put data instead of business object directly which is in same solution.
2) After having arguments they said what if client wants to host API and web on different cloud server and apply scaling only on API or may be he want to have different url for accessing API and Web (which is some what logical). So in that case should we call Web API from MVC application in same solution?
3) If we're hosting API and Web on different hosting so it means our Web will use WebClient and have HTTP call on each navigation. Is it right?
4) If we'll business object form both API and Web hosting on different server then if something change in BL will need to update build on both server.
5) Or we should create only one project for API and can add views or html pages to develop Web interface so in that way we can directly call API from ajax.
As per my knowledge #5 is the best solution or API is only for 3rd party access. If we have DB, EF, data layer and business layer in same solution then we should not use API to make HTTP calls and directly access business object. (correct me if I'm wrong)API is needed when mobile application or desktop or any one want to access application so we can have same repository and data layer.
In my scenario I've to create API as we also have mobile application, and in project API side we called business layer (separate project) and business layer communicate to data access layer (separate project). So my question is if we host our API and web to different servers then calling API which is a HTTP request may take longer rather than using method from business layer as we create the project and we've .dll of business layer. In API controller we just convert out put of our business to json format.
I've searched on internet but didn't get convincing answer. I've found a blog http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx discussing same point but again in that blog my question is why we need to consider scenario #3?
I think you have answered your own question in writing, but really this boils down entirely to what your requirements are, and perhaps more importantly, what the strategy for your application is.
First of all, using Web Api over accessing Business Objects directly (by which I think you mean through viewmodels etc) only makes sense if you are controlling access of data client side.
If you only have a requirement for consuming data from client side within a particular application, then hosting Web API within the same project makes sense. Sometimes, for instance when building a SPA or rich-client web app, then using Web Api within the same projhect is sufficient, as they are only intended to be consumed by that application.
Where you see a requirement for different versions of the same application (mobile, tablet, web etc), then moving the Web Api to a separate project makes sense, as each application can then access the same API. This Web Api would contain your data access and business logic layers within it. This allows complete separation of your projects then, and provides maximum reusability, and ensures consistency in data between different versions of your project. Obviously with this set up, your Web Api layer is seperate and can be tested/deployed/scaled separately.
So in summary, you need to consider your requirements and assess the technologies available to you to achieve them. Using the above I hope you understand where Web Api fits in and what it can provide.
I am new to web dev but I have managed to build my site using GWT and GAE. I use RequestFactory for client-server communications.
Now, someone wants to make mobile applications that use my backend.
I have found that RequestFactory works very well with Android. But I am somehow afraid it will not work with other "not-google" front ends (iOS for instance).
So my question is, can I make an API based on my RequestFactory backend (servlet) that can be used by any client? Any initial pointers as to how to implement it would be appreciated.
I guess technically it would be possible. However, if you want to create an api anyone can use, you probably want an api were you specify both how to communicate with the api and the content send/received by the api. With RequestFactory both the how and what is shielded by RequestFactory. So if someone wants to communicate with your api and can't use the RequestFactory code in the project, the how and what of RequestFactory must be reverse engineered, and could change anytime because it's not guaranteed. Not the most elegant way to go forward.
A better approach is define an open api were you specify the how and what. For example with
and apu based on REST (the how), communicating JSON data, and to specify the content format (the what). An example of such an api is the twitter api.
For your own project you could build on your api also, for example by using RestyGWT. Then you don't have to maintain both the code for the RequestFactory interface and REST interface. For other platforms there are probably several libraries available to make developing against a REST interface easy.