In my company we have several basic REST services consumed by our web and mobile applications. (Please read REST as only JSON over HTTP with only POST calls).
In order to improve the performance of the mobile client (network overhead of many http calls) we would like to be able to aggregate some REST calls.
We would like to find a generic solution so the mobile client is free to choice which services to aggregate.
The solution currently found is a generic REST service that receives the json with the list of requests and delegates
to a pool of threads the execution of each request. When all requests are completed the service collects all the
responses in a list and return it as aggregated response.
This solution has some problems:
The spring or javax validation is not applied (is invoked in the aggregating service)
Session scoped data is not available in servant thread (a workaround found via ThreadLocal)
Filters and Interceptors are not applied on the single request (no solution yet)
Potentially others issues yet undiscovered
Does spring(mvc) offer a better way to do the same?
Can HandlerInterceptor help me in re-implement the same logic in a safer way?
Thanks
Vito
Related
On most of the resources on google, I see one of the major advantage of graphql is said to be its ability to be as aggregator service but I did not find any concrete example how it is different from other http endpoints(or Rest endpoints) ?
My understanding is that in case of GraphQL, there will be single http endpoint for everything. Then graphql server will determine which particular
data fetcher will be called. That is provided in very configurable way.
But in case of other MVC based architecture or rest based architecture, end points are separate for each request and then the flow start.
So in a way graphql provides the single entry point(or we can say address) for each request then graphql take care of further branching, but in other above
mentioned architecture there are separate addresses(or endpoints) for resources/request. Is it because of this reason we say graphql can work as aggregator service or is it something else ?
The GraphQL's main advantage is to provide to the client ability to query everything (objects) it needed and display it to user without discussing/creating specification for every request/response in the application. And in some cases clients need different responses for the same request (eg views might look differently for web and mobile clients).
I believe you can create multiple GraphQL endpoint in your application based on context of your domain, but it might be misleading in most cases.
I read a lot about why REST is preferred over SOAP and a lot of practical situations for that. But I could not find an article/answer on When SOAP can be preferred over REST. Can anyone please explain me a real time practical situation where SOAP can be preferred over REST?
NB - Please don't mark this question as duplicate without reading the question fully. This is not a duplicate of REST vs SOAP.
NB - Please don't mark this question as duplicate without reading the question fully. This is not a duplicate of REST vs SOAP.
when should you use SOAP? Representational State Transfer (REST) implements the standard HTTP/HTTPS as an interface allowing clients to obtain access to resources based on requested URIs. It is important to note that REST based services are stateless because http/https is natively stateless.
One of the many benefits for implementing HTTP/HTTPS as an interface is can be found in caching. Caching can be done on a web service much like caching is done on requested web pages. Caching allows for reduced web server processing and increased response times because content is already processed and stored for immediate access. Typical actions performed by REST based services include generic CRUD (Create, Read, Update, and Delete) operations and operations that do not require state.
Simple Object Access Protocol (SOAP) on the other hand uses a generic interface in order to transport messages. Unlike REST, SOAP can use HTTP/HTTPS, SMTP, JMS, or any other standard transport protocols. Furthermore, SOAP utilizes XML in the following ways:
Define a message
Defines how a message is to be processed
Defines the encoding of a message
Lays out procedure calls and responses
As REST aligns more with a Resource View, SOAP aligns more with a Method View in that business logic is exposed as methods typically through SOAP web service because they can retain state. In addition, SOAP requests are not cached therefore every request will be processed by the server.
As stated before Soap does retain state and this gives it a special advantage over REST for services that need to preform transactions where multiple calls to a service are need in order to complete a task. Additionally, SOAP is more ideal for enterprise level services that implement standard exchange formats in the form of contracts due to the fact that REST does not currently support this.
A real world example of where SOAP is preferred over REST can be seen in the banking industry where money is transferred from one account to another. SOAP would allow a bank to perform a transaction on an account and if the transaction failed, SOAP would automatically retry the transaction ensuring that the request was completed. Unfortunately, with REST, failed service calls must be handled manually by the requesting application.
References:
Francia, S. (2010). SOAP vs. REST. Retrieved 11 20, 2011, from spf13: http://spf13.com/post/soap-vs-rest
Rozlog, M. (2010). REST and SOAP: When Should I Use Each (or Both)? Retrieved 11 20, 2011, from Infoq.com: http://www.infoq.com/articles/rest-soap-when-to-use-each
Which is the best architecture to handle multiple http requests sending a list of ids (with more than 1000 ids in each request) and each request will be a heavy time-consuming process that communicate with other systems (that uses SOAP or REST) and saves data into a RDBMS?
Should I send the ids in a POST HTTP request?
Should I use Spring Framework Async/Futures (without return) in a Resource/Controller REST to handle the Time-consuming process and return HTTP 202 Accepted (and maybe an ID to query the status of the process or the resource)?
Or Is it good if my Resources/Controllers REST only put the messages in a JMS Queue (maybe a persistent queue for each REST method) and Message-Driven Beans (for each method) consume the messages and process the request?
It is a good idea if my Resources/Controllers REST or a class acting like a proxy save the requests for my system and other systems responses in a database for logging purposes and to fix problems? Or should I use the retry feature in JMS for example?
I agree with dunni; however, your general requirements sound like JMS would be a good place to start. That would allow clients to drop off requests and allow back end components to work on the requests as they are able. Of course, you need enough back end power to get all the requests completed in a reasonable time frame.
I'd like to synchronize the state to all the clients interested in particular entity changes. So I'd like to achieve something like:
exposing CRUD API on entity (via HTTP/REST and websockets)
and routing the response (of the modifying calls) to websockets topic
So technically, I'd be interested in ideas to mix spring-data-rest with spring websockets implementation to achieve something like spring-data-websocket.
There are a two solutions coming to my mind, and in fact both would be:
spring-data-rest to expose my entities via REST/HTTP API
websocket controllers (used for the modification calls on entities)
The websocket controllers would look like this:
#Controller
public class EntityAWebSocketController {
#MessageMapping("/EntityA/update")
#SendTo("/topic/EntityA/update")
public EntityA update(EntityA entityA) throws Exception {
// persist,....
return entityA;
}
}
Scenario 1: Websocket API called from REST/HTTP API
Rules:
client request is always REST/HTTP API
response is REST/HTTP API for all the operations
moreover for modifying operations the websocket message comes as well
Technically, could be achieved, by:
calling the websocket controllers from the spring-rest-data events (namely in the AfterCreateEvent, AfterSaveEvent, AfterLinkSaveEvent, AfterDeleteEvent)
Still the solution seems quite sick to me, as I'd need to go for:
client A --HTTP request--> Server (spring-data-rest controller)
Server (AfterXXXEvent in the spring-data-rest controller) --websocket message--> Spring websocket controller
Spring websocket controller --websocket message via topic--> all Clients interested in the topic
Server (spring-data-rest controller) --HTTP response--> client A
Scenario 2: Websocket API independent from REST API
Rules:
client request is REST/HTTP API for non-modifying operations only
response is REST/HTTP API for non-modifying operations only
client sends websocket message for all the modifying operations
websocket message is sent to client for all the modifying operations only
Well, if no other ideas come up, I'd go for the later one, but still, it would be great if I could have somehow generated C(R)UD methods exposed via websockets as well, something like spring-data-websockets and handle only the routes in my implementation.
As I feel like I'd have to manually expose (via *WebSocketControllers) all the CUD methods for all my entities. And I might be too lazy for that.
Ideas?
Scenario 2 talks about, in the last step, a single client.But I thought your requirement was for a topic since you wanted multiple clients.
If I wanted to complete 2 for your stated requirement, then you might want to maintain a list of clients and implement your own queue or use a ForkJoinPool to message all your clients listening in on your WebSockets. Having said that, A topic is definitely more elegant here but overall looks too complicated with different interfaces
For all messages from client to server, just go with a simple wire protocol and use a collection to parameterize, it could be
RParam1.......
At the server, you need a controller to map these to different requests(and operations). Somehow does not look like too much work.
Hope this helps.
The same architecture has bugged my mind for a while now and it will be a long story if I want to mention all the drawbacks and advantages of it so let me jump into the implementation.
The second scenario is valid, but as you mentioned its better to perform the crud actions on same websocket session. This shall remove the need for HTTP handshakes on every request, and reduces the body size of messages, therefore you will have better latency. Meanwhile, you already have a persisting connection to a server, so why not make good use out of it?
I searched around for a while and after 6 years from your question, I still couldn't find any websocket protocols that can make this happen, so I decided to work on that by myself cause I needed it for another dummy project.
Another advantage of such protocol could be that it doesn't require much changes to your already written controllers. So it should be able to support Spring Framework (for example) annotations and make websocket endpoints out of it.
The hard part about implementing such protocol in another framework like spring is that as its not nice to create ServletRequest and ServletResponse and convert them to your own websocket protocol, you loose some advantages. For example, any http filter you have written in your application till that moment, will be meaningless because its not really easy to pass your websocket messages through those filters.
About the protocol itself: I decided everything to be passed through json format, alongside a unique id for each request so we can map callbacks on client side to the request id. And of course there is a filter chain to add your filters to it.
Another hard to deal thing here is Spring Security as that too works like http filters in some cases. In my own lib I could finally handle annotations like #PreAuthorize but if you are using antMatchers in your HTTP Security Config, it would be a problem.
Therefore, creating websocket adapter to call http controllers will have many drawbacks.
You can check out the project here: Rest Over Websocket. Its written for Spring Boot.
I'm looking for a way of implementing a simple API to receive log messages (for various events across various systems).
We've concluded an HTTP get request is the most open (lowest barrier to entry) for the different code bases and systems that would need to post to this server.
The server itself needs to provide an HTTP GET api where I would send a message e.g. logging.internal/?system=email&message=An email failed
However we'd like this to be non blocking so any application can throw information to this server and never have to wait (not slowing any production systems).
Does anyone know of any framework to implement this in Java, or an appropriate approach?
In java, for the server, you can use any implementation of JAX-RS for the Restful part, and when processing the message, just call an asynchronous EJB method ( http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html ), which will do the longer processing.
This will allow the RESTful request to return as fast as possible.
In this case, the only blocking part will be the http request/response.
If you want to make it less blocking, issue the RESTful request from the client in an Async method as well (or a Message Driven Bean if using Java EE 5).