The question:
Is it possible to run a C++ library on a HTTP server and access it via a web service in another language?
In more detail:
A few years back I did some development work using C# where I connected and used a Web service, I made a connected and accessed the web service methods such as:
var myservice = service.getResults();
Which would return all of the results from the database.. I want to do something similar in C++ in that, I have a C++ library that handles all of the database connections and provides a series of methods in order to access. I now want to open this up to a web method.
The issue:
I don't know how I would go about running this on a HTTP server and accessing using methods that are in different languages? For example, a few of our clients use PHP whereas some use Python. I want to be able to access the methods from each of these languages, so, for example (pseudo code(
PHP:
// Connect to API (Web Service) e.g. http://localhost:8000
$apiClient = new WebService::API();
$results = $apiClient->getResults();
This would then call (in C++):
function getResults()
{
// Run DB query
}
The implementation of the methods I am not struggling with. It's more to do with how do I make this appear on a HTTP server and can I use something like SOAP in order to connect and provide the functionality? I just want hints or resources in order to do this.
Related
Due to the fall of SOAP::WSDL which had generated me real Perl modules I have to look for something other in order to handle a SOAP service. The generated modules won't work starting from Perl v5.18.
I have the following situation with my web application.
I have a PSGI compatible, Dancer2 driven, persistent web application.
The web application handles multiple concurrent customers.
The web application is between the customer and an external SOAP service.
The SOAP service uses customer sessions via cookies which have to be integrated on the web application internally for the customer.
The web application holds an WSDL file copy of the SOAP service.
I'm looking for a module that creates an interface out of the WSDL file and handles parameter/schema validation and communication with the SOAP service. I would like to call a method (SOAP call) with parameters (SOAP call parameters) and receive a cleaned data or object structure of the response.
The problem is that the web application needs to handle multiple concurrent customer cookie sessions. So I need a module which offers the possibility to override the cookie jar for that particular request and extract the cookies after the request without causing interference with other concurrent requests.
I found XML::Compile which I can initialize as a singleton at web application start up. But with this solution I ran into problems with interfering other customer requests. So the requests are not separated. Initializing XML::Compile for every request is not the solution either because it will parse the WSDL and generate handlers over and over again for every request the customer sends to the web application.
Is there any solution/module that fits my needs or do I miss something with XML::Compile and it's possible with it?
Are you using Catalyst?
I've been happy using Catalyst::Controller::SOAP and its companion Catalyst::Model::SOAP to build SOAP/WSDL servers and consumers, being able to integrate Perl Applications even with Microsoft Document Literal-Wrapped thing.
Even if not using Catalyst you may probably learn from its code. It uses XML::Compile::WSDL11.
I am new to RESTful webservice. Whatever I have read over the internet about RESTful webservice, I came to know that REST works similar to servlet + webservice.
Our traditional webservice looks like JSP-> Servlet -> Service -> DAO -> Database.
Will REST replace Servlet in this heirarchy?
My ultimate goal is that my web application should support mobile application and normal browser also. Is it good idea to use REST in that case. If not, in what situation we should use REST?
I hope my question is clear.
Please help me.
Thanks in advance.
There are many ways we can achieve Machine to Machine communication.
Web services also helps communicating between applications made in different platforms.
For example a .net GUI can call a java server side program for data.
REST is one of that kind, based on HTTP protocol.
SOAP web service is heavy weight (using lots of XML) where as REST is simple and you can expose any of your APIS simply using REST.
A services exposed as REST services can be invoked by a client using on of the HTTP verbs GET, POST, PUT, and DELETE with their meaning same as in HTTP.
RESTful Web Services expose the state of its resources.
An 'Employee' data can be queried and represented in any format (Json, XML ...) using REST.
Rest won't replace the Servlet in your hierarchy, actually the HTTP based REST methods are written on this servlets.
Please go through this URL : http://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html
Using REST is not related to browser experience on mobile or other devices. It totally depends on the client side technology used and your browser compatibility with those technologies.
Using REST is a good idea to access data at client side using simple AJAX calls.
REST means Representational State Transfer. It is a way of thinking about architecting network communication between client and server, with the focus being on transferring a resource from server to client and back again.
To understand the significance of this first consider a different architecture, Remote Procedure Call. This is where the client calls a function on the server as if the function existed on the client.
So you want to edit a photo that exists on the server. Your client is a photo editing app that uses RPC to achieve this. You want to blur the photo so your client calls the blur() function using RPC, and the server blurs the image and sends back the updated image. Then you want to rotate the image, so your client calls the rotate() function and the server rotates the image and sends the rotated image to your client.
You might have noticed two issues. Firstly, every time you carry out an action on the photo the server needs to do some work and send you back the updated image. This uses a lot of bandwidth.
Secondly what happens if tomorrow the server developers (who might be nothing to do with the client developers) decide that rotate() is the wrong function name, it should really be rotate_image(), and they update the server. Your client continues to call rotate() but this now fails because such a function doesn't exist on the client.
REST is an alternative way of thinking about client/server communication. Instead of telling the server to carry out an action on the resource (eg rotate the photo), why doesn't the client not just get a representation of the resource and carry out all the actions it wants to (blur, rotate etc) and then send the new state of the resource back to the server.
If you did it this way the protocol to communicate between client and server can be kept very simple and will require very few updates. All you need is functions for the client to get the resource and functions to put it back on the server. The client will have to know how to blur the image and rotate the image, but it doesn't need to know how to tell the server to do this, it just needs a way of telling the server to save the updated image.
This means that the developers of the client can work away implementing new features independently to the developers of the server. Very handy if the developers of the client are nothing to do with the server (the developers of Firefox have nothing to do with the New York Times website and vice versa)
HTTP is one such protocol that follows this architecture pattern and it allows the web to grow as it has. There are a small set of verbs (functions) in HTTP and they are concerned only with transferring a representation of the resource back and forth between client and server.
Using HTTP your photo client simply sends a GET message to the server to get the photo. The client can then do everything it wants to to the photo. When it is finished it sends the PUT message with the updated photo to the server.
Because there are not domain specific actions in the protocol (blur, rotate, resize) this protocol can also be used for any number of resources. HTTP doesn't care if the resource is a HTML document, a WAV file, a Javascript script, a PNG image. The client obviously cares because it needs to understand the resource it gets, and the server might care as well. But the protocol between the client and server doesn't need to care. The only thing HTTP knows is that there is a variable Content-Type in the HTTP header where the server can tell the client what type of resource this is.
This is powerful because it means you can update your client independently to updating your server without updating the transfer protocol. HTTP hasn't been updated in years. HTML on the other hand is updated constantly, and web servers and web browser are updated constantly (Chrome is on version 33). These updates can happen independently to each other because HTTP never (rarely) changes.
A web browser from 10 years ago can still communicate with a modern web server over HTTP to get a resource. The browser might not understand the resource, say it gets a WebM video that it can't understand, but it can still get this resource without the network communication failing.
Contrast that with the example of RPC above where the client server communication will break if the server changes rotate() to rotate_image(). Every single client will have to be updated with this new function or they will crash when trying to talk to the server.
So REST is a way of thinking about client server communication, it is an architecture design/pattern. HTTP is a protocol that works under this way of thinking that focuses on simply transferring state of a resource between server and client.
Now it is important to understand that historically a lot of people, including web developers, didn't get this. So you got things like developers putting verbs into resource names to try and simulate Remote Procedure Call over HTTP. Things like
GET http://www.mywebsite.com/image/blur_image
And they would hard code the URI /image/blur_image into their client and then try and make sure the guys developing the server never changed the URI blur_image. You get back to all problems of RPC. As soon as the server guys move the resource blur_image (which is not really a resource to start with) to /image/blur_my_image the client falls over because it has that hard coded as an action to perform, rather than simply getting /image and doing what ever it wants to it.
So there are lot of examples on the web of doing REST wrong. Anything that tightly couples client and server communication is doing REST wrong. Your client should be able to survive URIs changing, or Content-Types being updated, without falling over. It can complain it doesn't understand a resource (eg Netscape Navigator 2.0 complaining it has no idea what a HTML5 document is), but it should complain that a URI has changed. This is the discoverability aspect of REST, which I haven't gone into too much, but basically your client should be able to start at the root of the server http://www.mywebsite.com and if it understand the content types it should be able to continue on to the resource it wants. You should never need to hard code a URI into your client other than the root of the server.
I could write a book about this stuff (and many have), but I hope that serves as a good introduction about what REST actually is.
#javafan I just checked the mykong example you provided. Please note that that is not standard http servlet implementation, it is a Jersy way of implimentinmg rest. So when you map all your URIs goes through this servlet com.sun.jersey.spi.container.servlet.ServletContainer and you write classes with annotation #path etc the Jersy runtime environment will do the necessary processing for you like converting the input and output objects to necessary formats (json, xml etc) depending on your configuration. You can write a simple servlet and add methods in it with #path annotation in it and that will be invoked inturn when you make the corresponding request. but the doGet and doPost methods are standard servlet methods that processes GET and POST method by default. You can ad another methods to the same servlet and add more qualifiers to process your request.
#GET, #Produces("xml") etc.
I hope this helps.
I was wondering how the Dropwizard client module should be implemented.
Source of confusion:
Dropwizard recommends you to separate your project as such:
In general, we recommend you separate your projects into three Maven
modules: project-api, project-client, and project-service.
On the Client section, it shows that you can instantiate the httpClient provided by dropWizard within a run method.
#Override
public void run(ExampleConfiguration config,
Environment environment) {
final Client client = new JerseyClientBuilder().using(config.getJerseyClientConfiguration())
.using(environment)
.build();
environment.addResource(new ExternalServiceResource(client));
}
I thought that the client module would wrap the httpClient, and any other service can use the client module, without caring which httpClient it is using.
So
how would a client module look like
When would you instantiate an httpClient directly within a service's run method (as done in the snippet of code above)
Thanks!
How would a client module look like
This is heavily dependant on your project scope and structure. For example, in one of my projects which is heavily database dependant, the Client module (or Service class in DropWizard's terminology) contains my DAO instantiations as well as hibernate initializations and a bunch of other init stuff (SQS, etc). I also use the HTTP Client and the Service class is where I initialize it. Reason being is that the Service class is the entry point and this is where you end up instantiating your Resource classes, etc. So having the dependancies instantiated here allow me to pass them into my resources as constructor params. If you were using something like Guice, then the way to go would be different since you have access to injection, etc.
When would you instantiate an httpClient directly within a service's run method (as done in the snippet of code above)
The HttpClient shown in the doc and your question is used when your project requires a Http Client. For example, lets say your DW project or one of the resources you are writing requires you to make a HTTP call to a twitter API. This is where the Http Client comes into play. You can actually use any Http Client library you want, however using the ones provided by DW (Apache Http Client, Jersey Http Client) allows you to create a 'Managed' Http Client there by allowing DW to start up, shut down and clean up the HTTP Client when the service is shutdown. So things like thread pools, connection pools, etc are all cleaned up by DW when you use its managed HTTP Client. In addition, the reason why you create this HTTP Client inside the run method is because you are then able to get a reference to the Configuration object's instance which will allow you to control the HTTP Client's settings via DW's configuration system.
Hope this answers your questions
I am not sure if this is the correct place to ask but since there are a lot of questions of this kind i ll go ahead and ask.
A year ago i developed an iOS application that was connecting to a server with HTTP requests exchanging JSON files etc. I was told at that time that the server was a web (REST) service. I didnt care much since for me was just a black box.
The last months i am developing a hybrid mobile application where i use native code + jquery mobile for the front end part and php + mysql for the back end part. The application is about registering new users to the data base , having users to subscribe in various kinds of events , get notifications on them etc. So for all the communication between the front ent(client) and back end(server) i make http requests(POST) , ajax calls using json files.
Is this a RESTfull Web Service? I am a bit confused on the definition of REST. According to wikipedia REST is :
REST-style architectures conventionally consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses.
So is what i am building a Restfull Web Service? Also do we call Rest only the server part or in general the client-server architecture?
Is it just a web Service? And if yes what kind of web service?
there is no difference when you invoke a controller (aka web service) from browser through http or from a client code (java, .NET or any language). when you want to invoke a service from outside world from your code.. you have choice of soap or rest .. soap is protocol, where as REST is an architecture style.. so REST is methodology of calling a service (which is simple http POST or GET call) from outside world .. not necessarily from a browser .. it may from client code which acts as browser to get response from outside world service..this is based on my experience..
I'd like to restrict access to my web service to registered clients. The first thing I thought of was to mimic that of AWS which, in a nutshell, issues clients a non-secret and secret key pair, and requires clients to prove knowledge of the secret key by using a cryptographic function of some of the HTTP request data and the secret key, then specifying the output of the crypto function in a request header. AWS does the same and checks that the expected signature matches what the client has specified. The secret is not transmitted, blah blah. This is pretty typical and not that interesting albeit useful.
http://mws.amazon.com/docs/devGuide/Signatures.html
http://chrisroos.co.uk/blog/2009-01-31-implementing-version-2-of-the-amazon-aws-http-request-signature-in-ruby
My preferred web server for web services is nginx. I'd like to start requiring similar request signatures in certain services. It makes sense to me to create an nginx module that handles request signature validation before ever sending the request to an upstream process (my web service instance(s)).
Do you know of such a nginx module? Do you know of a different one that I can base my work off of?
There's a decent nginx module writing guide here:
http://www.evanmiller.org/nginx-modules-guide.html
Please note that I'm not asking "how do I write a nginx module?" I'm simply trying to avoid reinventing the wheel.
Thanks!
If I'm understanding correctly, you could simply check for custom headers with an if($http_{yourheader}){} and validate that against a backend such as memcached, or proxy to a fastcgi script, or even use an embedded perl script (although this will be slow and could block).
AFAIK there aren't any specific standard or third-party modules that do this, but a combination of them could provide a suitable solution (eg; $http_{header} + redis backend, for instance).
Is there a particular reason you're not looking to use custom SSL certs? They would seem an adequate solution for restricting access with added security.