I've been searching around for the past few days trying to find a good article that addresses what I'm trying to do, but haven't really found much yet. Most point me in the direction of pre-existing C++ MVC frameworks.
I have a C++ application with a tiny embedded web server that responds to HTTP requests. What I want to do is create a routing pattern in which I can define service end points and the application will be able to use the proper C++ controller class.
For example, I could define my service end points like the following in a text file:
POST /login UserController::login()
GET /user UserController::get()
GET /dashboard DashboardController::get()
And have the C++ application call the appropriate class and static method based on the service I'm invoking. So in the case of the above example, if I submit an HTTP POST request to /login, then the Router should invoke UserController::login(). Service end points don't necessarily have to be defined in a text file, there could be another in-memory data structure they can be defined in.
I've been considering something like the Proxy pattern: http://en.wikipedia.org/wiki/Proxy_pattern
Or I was looking at this pattern: http://gameprogrammingpatterns.com/service-locator.html
Before going too far down a specific implementation I wanted to get some feedback from others on how they might go about implementing such a requirement?
Thanks!
Related
Firstly sorry if this question has been asked before but I'm a novice so even if it has I'm unaware of the language I'd even use to try and seek it out.
I'm beginning to learn about REST API's and it got me thinking. Is it possible to load the JSON response directly from the API server into the user's browser and bypass your own server?
Imagine you have say a Django app running on a server that accesses email messages from Outlook.com using the graph API.
I assume an ordinary flow would go something like:
User request->your server->graph api-> your server-> user browser.
It seems like a waste for it to hit your server that second time before it goes on to be presented to the user's browser.
Is there a way the Django app can render a template and effectively tell the browser "expect some data from X source, and place it in y location in this template"?
You could do that with javascript. You'd have to include either a script tag in your template, or create and include some static javascript files with the code.
I'd recommend learning and using the jQuery javascript library, as it makes what you're talking about much easier to implement. Research ajax requests, those are what you'll need to make requests directly to another server, bypassing your own
I have a REST API that I'd like to port to run as a collection of cloud functions. I'm wondering how to split up the different endpoints in the best way, and how much to rename endpoints to fit the GCF model.
For example, I have the following types of request.
GET /images
GET /images/<image_id>
POST /images
If this was implemented with GCF, these would all fall under the same function images, and then I would need to implement some routing based on HTTP method, plus a pattern match for <image_id>, etc..
I could however choose to implement something like...
GET /images
GET /image/<image_id>
POST /createImage
...so that each endpoint has a distinct function that is invoked. This seems more appropriate from a cloud functions point of view, but not at all appropriate from a RESTful design point of view.
What are the trade-offs for implementing cloud functions in one or the other of these ways?
I know how mythz generally feels about HATEOAS, but let's say that I have to follow the HATEOAS principles in my REST services and add links ("self", "parent", and other possible relations) to my DTOs.
Links like "self" and "parent" contains paths to the resources and those paths are of course related to my routes.
I'm using the following project/deployment structure for my ServiceStack REST service. If that matters, I'm using ServiceStack 3.9.71.
Service Gateway Assembly:
defines my DTOs. Each DTO has a factory creating that DTO from the corresponding domain object
defines operations and their routes
Service Implementation Assembly:
uses ServiceGateway to get DTO definitions and access their factories
does whatever domain logic requires and create the corresponding DTOs through the afore mentioned factories
Service Interface Assembly:
define my REST services and
calls ServiceImplementation from ServiceStack's HttpHandler, according to REST verbs (GET, POST, ...)
WHERE would be the proper place to add link information to my DTOs?
Option1:
In my Service Gateway, when I build the DTOs themselves. It seems logical:
I know what I need to know about my domain objects and I can easily
build the links. Except that my DTOs are now all including an
additional member (Links) and building those links forces me to
explicitly provide paths/routes (i.e. hard code them). Seems to lead
to a maintenance nightmare.
Option2:
In my Service Interface assembly, where I have the request context and
I know my routes. I can encapsulate whatever my Service Implementation
returns in a meta-object containing the response and a link
collection. However, to build that link collection, I sometimes need
information available at the domain (i.e. Service Implementation)
level. The big "con" side for me is that it creates a new additional
and artificial level in all my responses. Could be seen as a way to
standardize response formats but I don't like it.
Option3:
My hope is that I can write a wrapper generically "injecting" a "Links" member to all the DTOs
I return by hooking somewhere into ServiceStack in my Service Interface assembly. I haven't
investigated much in that direction because I feel I could be wrong on
the whole approach here.
Any advise / suggestion welcome. Thanks to all.
I'm not sure If I'm suggesting you option1 or option3, but this Is what I came out after trying to do the same thing.
I started from this answer.
Now you can access route metadata directly from filters.
So my current approach is:
=> Services create the dto responses and the next collection of hypermedia links that will be attached to the response. In this level you know the "operations" by type but not "how" you will build the routes. I think it is coherent that domain level deals with workflows of operations.
=> Within a response filter I get the available routes from Metadata, and build the routes from dto properties by convention. Finally routes are added to http header.
Caveats:
I'm mapping 1 dto - 1 route. This approach could be more difficult in other cases.
How to call webservice programmatically in asp.net without using add web reference?
My webservice url keeps on changing. Hence i need to capture the url at runtime and display the results.
Please advice.
You can change the URL of a web-reference at runtime (provided that the new address is hosting a service with the same schema that you originally used to create the reference):
MyWebService ms = new MyWebService();
ms.Url = "http://example.com/webservice.asmx";
ms.MyWebMethod();
Web References are definitely the way to go - whilst the classes that are created by the web reference are usually pretty heavy, all that strong typing makes it well worth your while.
you need to do the following steps.
PreReq :
First of all, you know the URL of web service.
Solution:
use wsdl.exe to create a proxy class and than compile it.
wsdl /out:myProxyClass.cs http://hostServer/WebserviceRoot/WebServiceName.asmx?WSDL
(there are other switches available
for wsdl. For Example to generate VB
class, you need to add switch
/language:VB)
Once your proxy class is generated you can easily consume in code.
MyProxyClass objService = new MyProxyClass();
DateTime time = objService.GetServerTime(); //Suppose service has method getServerTime
You can specify the end-point URL as part of the constructor of your client-side proxy class.
If you don't need to specify it during runtime then it can also be set in your web.config file.
Where are you trying to call the service and where the service file is located?
If the service is located on the same site. Why not just instantiate the class name from the service. Or just create a separate class and use interface
Preface
We are providing customers with our service API.
Each customer has own subdomain (e.g. sergii.ourwebsite.com) and own WSDL URL, it looks like http://sergii.ourwebsite.com/api/bsapi.cfc?wsdl
Also, all the websites (including API, of course) using the same codebase.
Problem
Say, two applications on same CF-server. This can easily happen, because some of customer websites are hosted on our servers.
Both trying to use own API WSDL, say:
http://sergii.ourwebsite.com/api/bsapi.cfc?wsdl
http://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl
And here come the problems.
When second website tries to register the web-service, CF throws an error:
Name:
https://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl.
WSDL:
https://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl.
org.apache.axis.wsdl.toJava.DuplicateFileException:
Duplicate file name:
/opt/coldfusion8/stubs/WS1985941973/api/Bsapi.java.
Hint: you may have mapped two
namespaces with elements of the same
name to the same package name. It is
recommended that you use a web browser
to retrieve and examine the requested
WSDL document to ensure it is correct.
If the requested WSDL document cannot
be retrieved or is dynamically
generated, it is likely that the
target web service has programming
errors.
Problem is that both of them are using same WSDL namespace, built from CFC path:
<wsdl:definitions targetNamespace="http://api">
Current solution
The only working solution for us is using the CFC aliases, like:
http://galashyn.ourwebsite.com/api/v1n1/bsapi.cfc?wsdl
http://galashyn.ourwebsite.com/api/v1n1/bsapi.cfc?wsdl
Each this CFC extends the parent like this:
<cfcomponent output="false" extends="api.bsapi">
<!--- this component used to extend base api version 1.x --->
</cfcomponent>
They produce different namespaces, which can be used without problems -- own namespace for each application:
<wsdl:definitions targetNamespace="http://v1n1.api">
<wsdl:definitions targetNamespace="http://v1n2.api">
This is pretty dumb workaround, but it works for now.
Other solution would be to use the single API sub-domain and identifying the customers by some key (we are already using them for security purposes), but it has serious negative problems for us because of some legacy code.
Please note that I don't know Java, so many specific advices are not so clear for me.
Google shows that this problem exists for years, but I can't find the smart solution.
So maybe here?
I can not "place the WSDL at a common URL for all customers" for now and I've explained why: because I have to use the sub-domains. If you know the way to put the WSDL at one URL and make service requests to another -- please tell me.
A WSDL is just an XML document that describes the web service. You can write (customize) it using CFML. For instance:
http://subdomain.domain.com/api/wsdl.cfm?api=bsapi&customer=subdomain
Then just copy the WSDL generated by CF, and use it as a template for your custom WSDL page. Replace the parts of the WSDL that are subdomain-specific and return the XML document. Be mindful of whitespace (perhaps see CFSilent, CFSetting), and consider using CFHeader to set the mime type to "text/xml".
Do all the customers use the same WSDL? Then place the WSDL at a common URL for all customers.
I also think you need to find out exactly what the error message means. I don't see where it has anything to do with the URL being used. If it had mentioned the URL of another customer, I'd have understood.
Part of this may be due to my lack of understanding of how CF works. In particular, what is this "registering web services" that triggers the problem when two customers do it?
Did you realize that the URL in the <soap:address/> element in the WSDL is only a hint? In many clients, it can be overridden. In a .NET client, just set the Url property of the proxy class. This should allow you to have a single WSDL at a single location, and yet have your customers each reference the proper subdomain, assuming there's some way to convey that information to them. For instance, if there is a way for you to know which customer is making the call, then perhaps you could receive calls on one URL and then redirect to the proper URL, or else use a SOAP Routing infrastructure to route to the correct one.
I hope you are not changing the namespaces from one customer to another. Namespaces have nothing to do with URLs, even if they happen to look like URLs.
There is a namespace attribute for the cfcomponent tag. You should be able to use this, along with cgi.host_name (? I'm at home, without docs) to specify a namespace that matches the subdomain being queried.
Something like:
<cfcomponent namespace="http://#cgi.host_name#/api/v1n1/bsapi.cfc">
Have caught this error message when tried to CFINVOKE webservice from localhost by test script located on same localhost (but in different folder). Sounds 'buggish' for me.