I have an Apache Ignite server running in a basic Java application. The Ignite REST api is exposed on a certain port. When I hit it from the browser, it is returning the desired response. However, from an Angular app, I am getting CORS error.
Is there any solution to this? Note that this application runs Ignite REST api (the one which is giving the CORS). How do I allow cross-origins inside the Ignite REST api?
Unfortunately I haven't heard about the right way to achieve that.
CORS filtration in Jetty is configurable through Servlet filtration API. This functionality is provided by ServletHandler. It seems that Ignite utilizes its own Handler to serve HTTP requests. As far as I understand it doesn't support cross-domain requests.
In general I don't think that it's good idea to direct HTTP request to an Ignite cluster from a browser. It doesn't look absolutely secure and architecturally correct. I'd prefer to have separate back-end application which should be responsible for processing of your Angular application load.
Related
I'm considering using gRPC for a b2b API and I can't quite figure out if gRPC server can run on top of another http2 capable web server?
In the examples provided on the official site the gRPC API is always running on its internal netty based server on a particular port.
So, if let's say I have several gRPC applications it looks like I'd have to run them on separate ports.
But I would like to have a single API entry point (a web server like jetty on a single port 443) that would manage the URLs and map them to the particular gRPC service implementation.
Is it possible with gRPC?
No, grpc-java cannot respond to RPCs as a servlet.
Servlet containers supporting HTTP/2 are very new and gRPC hasn't investigated them much yet. It does seem feasible to use the async servlet APIs to implement a gRPC server (as an alternative to the Netty server), except possibly for trailers. It's not 100% clear how to send trailers when the server is HTTP/2, since a common technique with HTTP/1 was for the servlet to manually perform chunked encoding which does not exist in HTTP/2. In any case, it isn't implemented.
Edit: An issue is now open GitHub.
I'm trying to implement a desktop application that could send http messages to an already open local web application so that it will be updated with this information.
Any suggestions?
The only idea I came up with is sending http requests to the relevant web server and implementing on the web server a servlet that will update the relevant web page according to userID.
Anyone has a more elegant solution?
As far as I understand you you want to implement servlet that performs HTTP connection to other, external server. If I am right the following discussion will help you:
How do I make HttpURLConnection use a proxy?
Take a look on the answer that explains how to use Proxy class introduced in java 1.5.
We have an AppEngine app with that we would like to use with Google Endpoints. We need to support a web client as well as mobile clients which is what makes Endpoints attractive to us since we can easily generate Android and iOS client APIs.
The problem is that cloud endpoints currently don't support custom domains, so our web client cannot directly communicate with the endpoints (the mobile clients do not have this issue).
Here is what we've tried already:
CORS requests from the client to the appspot.com domain. The problem with this is since our request do not meet the requirements for simple CORS (custom headers, cookies, etc.), a preflight request must be sent with every request, which slows everything down
Client makes request to our custom domain which in turn makes a request to the appspot endpoint. Again, the extra request is not good for performance
We've also tried setting up a duplicate Jersey REST API just for the web client. We double annotate all our methods (once for Cloud Endpoints and once for Jersey) and the web client accesses the Jersey API and the mobile clients access the Endpoints API. This works pretty well except that Jersey and Endpoints use different exceptions. So if we want to throw a 404 Endpoints exception that will mess up the Jersey response and vice versa.
Are there any other options? We want to use the power of Endpoints for generating mobile clients but also get around the custom domain limitation for the web client.
We ended up ditching Cloud Endpoints entirely and went with a pure Jersey REST API instead.
To deal with our need to generate mobile clients for the API, we annotated our API with Swagger. As an added bonus, Swagger seems to support more client generation than Cloud Endpoints and also makes it relatively easy to setup your own client generation from a template if your target language isn't directly supported.
Jersey + Swagger was not as easy to setup as Cloud Endpoints, but it is more customizable and allowed us to get around the custom domain restriction imposed by Cloud Endpoints.
Google Cloud Endpoints 2.0 now supports custom domains. If you are using Google Cloud Endpoints 1.0 you can migrate by doing the following:
Update your dependency to use the new artifact. In Maven, this looks
something like below:
com.google.endpoints endpoints-framework 2.0.0-beta.8
Remove the legacy dependency, which is the appengine-endpoints artifact.
Update the API entry point in your project web.xml file:
Rename all occurrences of SystemServiceServlet to EndpointsServlet.
Replace all occurences of the path /_ah/spi/* to the new required path /_ah/api/*
See:
https://cloud.google.com/appengine/docs/java/endpoints/migrating
https://code.google.com/p/googleappengine/issues/detail?id=9384
Easiest solution is to use reverse proxy.
For example if your application is http://myapp.appspot.com, create simple html page on http://myapp.com and redirect to http://myapp.appspot.com using javascript.
Index.html on http://myapp.com.
<html>
<head>
<script>
windows.location = http://myapp.appspot.com;
</script>
</head>
<body></body>
</html>
It has one more advantage: if you put your proxy page on another hosting (not appspot.com) your application ( http://myapp.appspot.com ) will be accessible from China.
I have a Spring-MVC webapp (3.0.5-RELEASE) which needs to access JSON webservices from another webapp on a different sub-domain (from the client/browser via AJAX).
I've solved this in the past by either:
writing a simple controller that proxies the requests, using Apache Commons HttpClient to handle the requests. Thus overcoming the cross-site/cross-origin request security limitations of most browsers
implementing a JSONP service on the server side (when calling our own JSON services) - not always possible
In the case where JSONP is not possible, is there a better way of doing (1.)?
and/or
Is there a library that will handle this for me? So I don't have to write all the HttpClient code myself - its not a lot of code, but I wonder if I'm (badly) re-inventing the wheel.
I have often had to consume third party web services (API), and as you mentioned, JSONP is not always an option. This is how I go about designing:
If the API is user centric, it has to provide a jsonp interface and that's what I will use. User centric means that you cannot perceive any reason to call the API, do some computations with the response, may be call one of your ajax services and then combine the response and show the user.
If my use case includes calling the API, and then acting on the response, like calling additional services from my application, combining the data and then showing it to the user, I would prefer not doing this in the browser. I would instead use RestTemplate and make backend api calls to the service. In which case there are no cross domain restrictions.
The only case where using a Server Proxy to bypass jsonp is when you are creating a Product that allows people to build custom plugins, plugins which are hosted on your page, but need to make Ajax calls to the app developers servers. This is a very involved case! (As as example look at how Apigee creates Public Facing REST API around your existing urls, or how Zendesk allows you to develop apps)
Hope this helps.
I would like to configure a webservice so that once the accept queue is full the service returns 503. Currently, these requests seem to just time out.
I did set paramters like maxThreads and acceptQueuesize (as described here: http://www.restlet.org/documentation/1.1/ext/com/noelios/restlet/ext/jetty/JettyServerHelper).
But the service does not respond with 503 once the acceptQueue is full.
It seems jetty's ThrottlingFilter (http://www.mortbay.org/jetty/jetty-6/apidocs/index.html?index-all.html) is what I'm looking for, but I don't know how to apply within my restlet service.
You won't be able to take advantage of ThrottlingFilter unless you deploy your application as a WAR file into Jetty. JettyServerHelper bootstraps Restlet as a standalone server using Jetty to accept HTTP connections and hence cannot utilize a Servlet Filter. I'm not sure if there is anyway to utilize similar processing logic from the ThrottlingFilter in Jetty outside of the Servlet world or not.