What is the best strategy to generate links or urls to other resources in a self-hosted WCF WebApi application, without hard-coding something like host or port, etc.
Is there something like a route-helper?
Currently, AFAIK, there isn't specific support for link/url generation. However, you can access all the required information (e.g. scheme, host, port, uri template) via the description model. See https://pfelix.wordpress.com/2011/05/08/wcf-web-apidescription-model/
Related
I have lot of webapis which are developed and deployed independently.
Each API would have routing for ex:
api/FirstApi
api/SecondApi
These will be deployed under www.myapis.com/.
If I create application for each of the api(s) in IIS, I would access the api as follows
www.myapis.com/FirstApiApp/api/FirstApi
but I want to access it as.
EX: www.myapis.com/api/FirstApi
Or: www.myapis.com/api/SecondApi
I want to remove the application FirstApiApp OR SecondApiApp from the url.
Is it possible to configure this pattern in IIS?
You could have the following structure:
c:\inetpub\wwwroot\api\FirstApi
c:\inetpub\wwwroot\api\SecondApi
And then have a website in IIS mapped to c:\inetpub\wwwroot and inside the api folder you have the 2 applications configured like this:
This assumes that you should drop the api/FirstApi routing from your Web APIs and map them to / directly because the first part will be provided by IIS. If you don't do this the request will become www.myapis.com/api/FirstApi/api/FirstApi which is not the goal here.
This being said, personally I would recommend you against doing this. A better approach would be to have a reverse proxy such as nginx or HAProxy in front which will route requests to /api/FirstApi to for example backend_node:8080 and requests to /api/SecondApi to backend_node:8181. This would allow you to deploy your Web APIs in two separate website in IIS listening on two different ports and keep the routing job to the application layer and not the infrastructure.
In my WCF service application , images are saved into application directory. So in one of the service call, it returns the image(http request to the url- http://mydomain:88/Images/Tree/test.png) to the client application.( a mobile application). The url exposes the application directory, so is this a good practice? All the call to the service is protected using basic authentication. But still is this good practice to exposing the directory structure in url?
Thanks.
All you've done is expose a little information to the world about your directory structure behind the scenes - probably not a "best practice". But generally, I'd say you're safe if:
you don't expose the directories to browsing (like via an IIS
setting)
the web service or proxy is located behind a firewall within a
DMZ
the WCF requests are authenticated/authorized before
content is delivered.
You can fix this without too much work, though. Assuming the "Test.png" is the file the client is trying to download, change the host-side endpoint so that it's just ".../Images/Tree/Connect" that receives the file name as a parameter in the Get(). The host and clients would have to change, but it's not a big change.
I'm building a WCF router which needs to act as a proxy for a number of internal web services (WCF and ASMX). The routing part is fairly straight-forward, but I can't understand how the service metadata exchange would work in this solution.
In other words: how would a client obtain metadata for an internal service behind the router? Do I need to manually supply WSDL files to the consumer? Can I somehow setup the router to return the metadata for an appropriate internal service?
Or perhaps my architecture is completely wrong?
I see 2 options here:
It may be an option to create a "non-transparent" proxy, if you don't want to expose the internal addresses. The advantage is that you can do more than just routing messages (i.e. such proxy may serve as a "security boundary", unwrapping ciphered messages and passing them plain to the internal endpoint). It can also provide an "interoperable level", exposing a WCF service as simple SOAP using same datatypes/message XML structure. The downside is that you'll have to update its code along with the proxied services
You may implement a WSDL rewriter. With it, you can mask the internal service URL on-the-fly - depending on your conditions, a simple string replace may or may not suffice.
Refer to:
Message Inspectors
IWsdlExportExtension
The same "router service" can also be used to get the individual WSDL for internal services behind the router.
Check out this thread
Have you considered using a simple HTTP Proxy instead? All WCF using REST or SOAP are at their core HTTP requests. It seems like the routing functionality (which I am assuming you are basing on hostname, URL path or parameters) could be performed by proxying the HTTP request without needing to understand the contents. ASP.Net will do a fairly good job of sanitizing incoming requests on its own, but you could always add additional custom filtering as necessary.
I am developing a wcf service (basicHttpBinding) that should also be consumed by non .net clients (e.g. Java clients). But now I wonder how the client can define his client config file. Or is this file only needed for .net-clients? (I am thinking of configurations like maxReceivedMessageSize or maxItemsInObjectGraph for example).
Each development platform (call it as you want: SOAP stack, Framework, API) has its own way to configure communication. You don't need to bother with it. You just need to expose correct WSDL and client's developer will be responsible for configuring the client application based on his needs.
If you want to extend documentation of your service in WSDL you can use wsdl:documentation. WCF doesn't offer it by default but you can use this technology sample to extend WCF. You can use such documentation for example to describe that service operation can return large amount of data. Another approach to add wsdl:documentation is using WCF Extras.
From the sound of it, the client shouldn't have access to those configuration options. For instance, why should a client to the WCF service be able to specify the maxReceivedMessageSize?
What you probably want to do is define these configuration options on the server-side. If a client makes a call and there is a conflict with one of your options (i.e. the client exceeds maxReceivedMessageSize), you'll want to throw a SoapException back to the client.
If you want to let the client have access to the configuration settings before he or she sends a request, you can always implement a simple web service method that sends back the values.
I'm trying to build a WCF self hosted service (eventually in a windows service) that will receive binary and text base messages from remote thick clients that have no accounts on my hosted machine. I'm trying to figure out both my binding options and security options, and in reading the patterns and practices guides, my head has completely spun around at least once.
The clients would be authenticated against a custom SQL based method, so I'd like to be able to pass that info in the initial login request and then set an authorization token of some kind. (This part of the problem is probably outside the scope of the question, but I included it in case it might make a difference.)
Any thoughts at all would be very helpfull.
Ryan
The choice of binding and security option depends on the usage of your WCF service. Is it just for your rich client or are you planning to expose it to the world as API? If it's just for your rich app, does it run on LAN or over untrusted, unreliable Internet?
With WCF you can configure the service to expose multiple endpoints with different bindings, for example both SOAP and REST. In general, I'd start with something stateless and lightweight like basicHttpBinding and webHttpBinding, passing user and password on every request. Once you have that up and running you can optimize cache authentication, provide binary endpoint etc.. only if it actually helps.
There's no need to have just one binding. Having said that if it's self hosted you're "on your own" here. I've never looked at what's involved.