Does API Gateway handle the aspects of Transformation of Request/Responses for/from multiple APIs Or does it ideally handle this aspect at all?
How does it fit in the landscape where Asynchronous messaging is used instead of Synchronous REST call?
Any insights will be appreciated.
Related
Can Azure API Management fulfill the below requirements or do I need to use Application Gateway as well along with Azure API Management?
Route traffic to various microservices
Cope with traffic demands and scaling
Support API versioning
The microservices are hosted on Azure App services.
Thank you
Whether API Management can do this, depends on what you exactly mean by these requirements.
Route traffic to various microservices
As you mention the microservices are Azure Web Apps, I assume you mean different microservices to route to, based on a different endpoint.
You can route a request based on the contents to a certain endpoint.
Cope with traffic demands and scaling
Azure Web Apps are scalable by default, and the traffic manager takes care of it. APIM can only handle traffic demands and scaling to the platform itself. You can scale up or out, even automated based on rules. However, as scaling might take some time it's recommended to monitor the capacity metric to accomodate for increasing load.
Support API versioning
APIM is 'just' an virtualization layer between the customer and the API. So having API versioning on APIM only makes sense when you actually do versioning on the API. In APIM you can create version sets which specify the versioning strategy for the API, based on header, path or querystring. An API can be deployed in APIM based on the version set, which makes it a versioned API.
I have a pretty straight forward question. If someone are to do a commercial Android project using AWS, is it best practice to build a RESTlet or Protocoll Buffers API (a server/service) for the app to communicate with which then send database requests to AWS, or do they skip the API and just communicate with the DynamoDB service directly which would be less code but not as cute?
I would say that decoupling your app from DynamoDB will help with scaling. What if you decide to not use DynamoDB anymore? You only have to change the service, and that can be transparent to the app and its users.
If your app can tolerate it, you could try an asynchronous approach. This will decrease latency and increase flexibility/scalability. An example of this: app pushes an event to an SNS topic. From there you can have SQS queues subscribed to this topic to retain these messages, and then have a Lambda function/web app that processes the queue.
I do have an existing JAVA based SOAP API and I a, trying to build a REST API instead.
JSON is not preferred for big payload.
(How Big is Big for JSON)
My Report generation API returns a XML payload ranging from 350kb to 1MB.
Not sure what the suggestion is.
Question-
Should I go with REST/JSON or REST and something else?
Also what is the best design opinion for me to consider while moving from SOAP to RESTful
Any tools or framework, you may recommend?
Sorry if this is very open. I can provide more detail, if you suggest?
The technology I intend to use is all Java based
Well SOAP/XML is bigger in any case than a REST/JSON payload. Besides JSON works well even in this size range.
I would consider thinking your API from start while considering RESTful best practices. JSON is simpler than SOAP and with some practice RESTful design will seem natural.
Finally in Java you may use JAX-RS
Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats.
https://code.google.com/p/protobuf/
What is the best technique to push notifications from the cloud to a client? REST does not seem to support this. In particular, I have JSON objects representing world state going to the cloud and want to be able to notify a client when that state changes.
All HTML5 implementations I've seen support full duplex communication via WebSockets.
If you're using Google App Engine you can use the Channel API. https://developers.google.com/appengine/docs/java/channel/
If you're using JBoss you can use the Errai Framework. http://errai.github.io/
I'm sure there are a lot of other options out there. And there's always email.
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.