What are the security practices that differentiate system apis to experience APIs in API lex and layered API architecture
The question is very open but I believe that the more important practice is usually that people want to ensure that System APIs to be called only by previous level APIs and not by users and clients.
Related
Project background: Building an API driven Learning Management System. The back-end system will be receiving data from multiple systems and interfaces: web, mobile, VR.
Looking at API Gateways to front our APIs. Preferably an Open Source API gateway but need to be sure that the support and service is available. Tried out Tyk.io and it feels like it might be the way to go. Been reading other StackOverflow threads around this and looks like TYK's gateway fairs quite well against the likes of Kong and WSO2.
Main areas of consideration for us are:
Rate-limiting
Open ID Connect authentication
Analytics
Scalability
Hybrid model of hosting - combination of on-prem and cloud depending on compliance requirements of educational institutes (Probably rules of AWS' gateway)
It would be really helpful if anyone who is using or has used TYK.io for their production projects can share their experience, especially for enterprise clients/projects.
Full disclosure: I work for Tyk, so of course think that Tyk is the best fit for your project ;)
Seriously, though - Tyk can do all those things you’re after. Here are some links to the documentation for each item that is big on your list:
Rate-limiting
Open ID Connect authentication
Analytics
Scalability
Hybrid model of hosting
You can also post on the Tyk community for help, if you haven’t already, or search to see what else others have said.
The Tyk Open Source API Gateway will do everything you need, even outputting analytics to difference sources, like ElasticSearch, Mongo or just CSV.
In addition, you can also use our API Management Platform to control your open source gateway. The Tyk API Management platform includes a Dashboard with analytics and out-of-the-box developer portal. Tyk is free to use, under a developer license, to manage a single gateway node, ideal if you are doing a POC.
Hope this helps and please keep in touch to let us know more about your use case.
What tends to be the industry standard for API authentication? I'm looking at implementing an API for CRUD on a member management system and need authentication. I came across this article using JSON web tokens. I've also seen tutorials that mention using session based authentication, as does this one.
What is the industry standard for authentication of users to API access?
EDIT:
Is this article explaining tokens vs session based still relevant? It's over two years old.
I'd say that OAuth 2.0 has taken over as the dominant API credential in use, but it's far from the simplest option.
Me and my team will be working on APIGEE which is an API development platform to expose some services in our application. I am going through their documentation and also trying to understand the need of APIGEE or any other API development platform like Mashery. One very good article on the need of API proxy as been very well explained in the given link, http://apievangelist.com/2011/06/11/the-battle-for-your-api-proxy/
One question that i am confused about is What is the difference between APIGEE and any ESB like ALSB or Mule. We know Apigee too supports message transformation via policies and protocols like http/https/soap.
Can anyone please tell me the differences between the two? Does Esb support more protocols like SMTP/JMS etc.
Any information is most welcome
Though API management definition is still evolving but API management is defined as transforming APIs to reach to your target audience [ here is a good description - http://searchcloudapplications.techtarget.com/definition/API-management].
This technology has it's root in SOA but different from ESB.
ESB is more for system-to-system integration but API tends to be securely exposing your internal systems in a managed fashion to wider audience - we call them "developers".
ESB tends to be equipped with many adapters and strong message oriented middleware for supporting different interaction patterns. It is also generally couple with business process management software to automate internal processes by integrating multiple services or systems.
API management also does some integrations and orchestrations but focus is more simplifying the interfaces to easier consumption of the services - that's why it is always come with developer on-boarding capabilities, security , caching , api design , oauth etc.
Apigee gateway service [ API management platform ] has support for limited JMS and SMTP functionality serving our diverse customer base and our technology stack is capable of building other protocol support.
Many API management products [ including Apigee gateway ] also include API analytics to help you getting insight of API program and API traffic.
Nowadays, APIGEE and Mule are direct competitors in the API management offering realm. In the case of Mule, there was a great transformation on the company, towards API-ification of all systems. Current Mule runtime is integrated with strong API management capabilities including analytics (functionalities from the former Mulesoft's API Gateway product, which was merged into the Mule runtime since v3.8.0), as well the usual ESB capabilities. Further info is available at Mule dev doc site.
API Management & ESB are two different capabilities which may have little overlap in terms of exposing the integrations themselves as API's which Mulesoft does.
Apigee also supports few ESB capabilities but it's not as exhaustive as Mulesoft. Ofcourse ESB is bigger scope & if you don't need that capability & just need API management with Full API lifecyle Mulesoft & APIGee both serves that need.
Personally I am a big fan of Mulesoft's API policies which comes out of box & it's an exhaustive list.
I have few questions regarding HornetQ:
What are differences between HornetQ core API and the JMS API ?
is there any advantage or disadvantage on using one of these ?
Is it true to say if I use the core API and then I decide to
change my Messaging Bus (let's say to ActiveMQ) then I have to
change all my codes ?
HornetQ Core API is a proprietary API from HornetQ, while the JMS API is a standard API defined by the Java Community Process.
There are a few features that are not supported on JMS API, that are available through core-api:
It's not possible to have multiple consumers on a single topic subscription (say if you wanted to have multiple consumers to scale it better)
It's more generic on how you create the subscription. You just create a queue within an address. Very simple.
We have a nice API for asynchronous confirmations. No need to block ever if you use this feature.
The advantage on the JMS is portability. Your code stays the same if you decide to move between providers.
The disadvantage on JMS is that it lacks some features and it's a bit verbose, what's under works on JMS 2 JSR right now.
Yes, because as I have said here, Hornetq-core api is a proprietary API, hence it will only work on HornetQ. The same way as some message systems will have a proprietary API.
If you encapsulate your Messaging access you can minimize that a lot though where you could just replace a single class on your system using standard OO techniques.
Can anyone explain at a beginner-intermediate level the terminology of "bus", "transport" and "endpoint" in the context of an enterprise service bus? I'm a C# developer with a few years experience now, but only just starting working with an ESB.
It seems that the "bus" is effectively a queue to which you can send and receive messages. I'm fine with that. However I'm working on some existing code using NServiceBus and I think if I grokked the "endpoint" and "transport" terminology I'd make a massive leap forward in my understanding.
Let me try to clarify those terms to you:
Bus in context of ESB architecture should not be considered as simple queue for message dispatching. To allow integration of different services, ESB provides much more. Important additional functionalities of ESB:
Routing. Messages can be routed to different services, depending on message content or endpoint specification.
Message Transformations/Mediations between different formats
Transport protocol conversion. ESB should be able to seamlessly integrate applications
that use different transport protocols (JMS, HTTP/S, pure TCP, etc.)
Message enhancement. Messages can be enriched with missing data before further processing.
Security
Management and Monitoring
Those functionalites are provided by services that operate within ESB. Services connect to each other via endpoints - uniform, unique "addresses". Messages dispatched between endpoints are using unified transport (method/protocol that encapsulates message's payload). Application that natively use different transport, need to connect to ESB via suitable adapter - service that will provide necessary transport conversion. This way applications that use ESB are decoupled from each other and don't need to provide conversions themselves.
Of course, those are only very brief descriptions of terms. Remember, Enterprise Service Bus is only catch-term for specific kind of architecture (or concept), but it is not standardized in any way. So specific implementations can be very different from each other.
If you are interested in standardized ESB, you can take a look at JBI (Java Bussiness Integration). There are several open-source implementations of JBI avalable, among them Apache ServiceMix, Mule, OpenESB. Very good introduction to ESB technologies is presented in "Open Source ESBs in Action" book published by Manning.
I would recommend looking at resources related to Enterprise Application Integration (EAI), which revolves around the ESB and various models and patterns used to integrate solutions. Think of it is a GoF for ESB architectures:
http://www.enterpriseintegrationpatterns.com/
and
http://www.enterpriseintegrationpatterns.com/toc.html
All of these patterns would give you an idea of what people use ESB's to achieve and the patterns are useful for providing common pitfalls of do-it-yourself ESB integration. I've learned an immense amount through that book and through people that source from it.