Usually you do consider querystring params as case sensitive in most frameworks in terms of the backend matches.
But I just tried in WCF, is there some built-in hack that allows incoming querystring params to be case insensitive??
Related
Other than readability, why would you use logical URIs?
Surely sending a GET request to /users (to get all users) is the same as /users.php
Surely sending POST to /users/dave with some data to update Dave is the same as /users.php?name=dave&phone=1234
You decide what to do based on the HTTP method, and then you pull apart the URI string anyway.
Logical URIs decouple client code from the implementation details of the server-side code. In your /users.php example, .php is an implementation detail. If I publish that URI as an endpoint, clients will depend on that specific PHP script. I won't be able to switch to a Java or .NET implementation without changing client code. (Or I'd have to do some really unsavory remappings on the server.)
I am trying to implement OAuth in a web service such as:
http://www.codeproject.com/Tips/372422/Secure-WCF-RESTful-service-using-OAUTH
Each time, when the Authenticate method is fire, WebOperationContext.Current.IncomingRequest exists, but UriTemplateMatch is null. This is even the case when using the WCF Test Client, so my client app isn't the problem. Ultimately, I need to access the QueryParameters under UriTemplateMatch.
In the Authenticate method, this is where the code breaks:
NameValueCollection pa = context.UriTemplateMatch.QueryParameters;
Looking for a different solution than this so everything is processed in one request:
https://stackoverflow.com/questions/7344478/using-the-wcf-http-web-api-uritemplatematch-is-always-null
Also, just as much as a solution, I am looking for a reason why the UriTemplateMatch would be null only in the case of a WCF Service. There are hundreds of articles on the presence of this problem, but I haven't found a good solution and/or explanation. I think I may be missing something in my web.config.
It seems that this solution is expecting incoming calls like :
http://localhost:49262/TestProject/Service.svc/user/123?oauth_consumer_key=key&oauth_nonce=10a33ed37b549301644b23b93fc1f1c5&oauth_signature=cUobFDxVB5wjPe9X2XICJ6awmnE%3D&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1289976718&oauth_version=1.0
There are two ways to attach oauth parameters, one is through headers, another is through query string, both are valid, so I choose to attach oauth parameters in query string. There is not any problem to retrieve them from IncomingWebRequestContext.Headers if those oauth parameters are in headers
This solution is not from me. Check this link.
Assume i've read a lot about versioning a restful api, and I decided to not version the the service through the uri, but using mediatypes (format and schema in the request accept header):
What would be the best way to implement a wcf service or a web api service to serve requests defining the requested resource in the uri, the format (eg. application/json) and the schema/version (eg player-v2) in the accept header?
WCF allows me to route based on the uri, but not based on headers. So I cannot route properly.
Web Api allows me to define custom mediatypeformatters, routing for the requested format, but not the schema (eg. return type PlayerV1 or PlayerV2).
I would like to implement a service(either with WCF or Web Api) which, for this request (Pseudo code):
api.myservice.com/players/123 Accept format=application/json; schema=player-v1
returns a PlayerV1 entity, in json format
and for this request:
api.myservice.com/players/123 Accept format=application/json; schema=player-v2
returns a PlayerV2 entity, in json format.
Any tips on how to implement this?
EDIT: To clarify why I want to use content negotiation to deal with versions, see here: REST API Design: Put the “Type” in “Content-Type”.
What you are bringing here does not look to me as versioning but it is is more of content negotiation. Accept header expresses wishes of the client on the format of the resource. Server should grant the wishes or return 406. So if we need more of a concept of Contract (although Web API unline RPC does not define one) then using resource is more solid.
The best practices for versioning have yet to be discussed fully but most REST enthusiast believe using the version in the URL is the way to go (e.g. http://server/api/1.0.3/...). This also makes more sense to me since in your approach using content negotiation server has to keep backward compatibility and I can only imagine the code at the server will get more and more complex. With using URL approach, you can make a clean break: old clients can happily use previous while new clients can enjoy the benefits of new API.
UPDATE
OK, now the question has changed to "Implementing content-negotiation in a RESTful AP".
Type 1: Controller-oblivious
Basically, if content negotiation involves only the format of the resource, implementing or using the right media type formatter is enough. For example, if content negotiation involves returning JSON or XML. In these cases, controller is oblivious to content negotiations.
Type 2: Controller-aware
Controller needs to be aware of the request negotiation. In this case, parameters from the request needs to be extracted from the request and passed in as parameter. For example, let's imagine this action on a controller:
public Player Get(string schemaVersion)
{
...
}
In this case, I would use classic MVC style value providers (See Brad Wilson's post on ValueProviders - this is on MVC but Web API's value provider looks similar):
public Player Get([ValueProvider(typeof(RequestHeadersSchemaValueProviderFactory))]string schemaVersion)
{
...
}
I'm reading about this ajax response that describes ways to prevent Javascript based exploits.
Does it make sense to apply this technique to WCF-based services that return JSON?
How would this be implemented server side?
How would the client consume it?
There's one way WebScriptEnablingBehavior -- the behavior of choice if you want a WCF service that works with ASP .NET AJAX -- deals with this. By default, its response mode is "WrappedResponse". If you watch this in action using Fiddler, it means that every response from the service -- even a simple number -- will wrapped in {d:} wrapper as follows:
{ "d" : return-value }
On the other hand, WebHttpBehavior is XML out-of-the-box, but if you switch it to JSON, you can choose between WrappedResponse and BareResponse. WrappedResponse is similar to WebScriptEnablingBehavior (if I remember correctly), but BareResponse would be unsecure JSON transmitted back as a direct return value.
I'm building a WCF service based on a W3C specification which defines a RESTful web service endpoint that accepts "application/x-www-form-urlencoded" post data. WCF doesn't support this type of message encoding by default and I have found a number of different examples of creating a contract that looks like this:
XElement Query_Post(Stream postData);
And then within the implementation decoding the postData stream using the HttpUtility.ParseQueryString method.
Does anyone know of a more strongly typed way of supporting "application/x-www-form-urlencoded" in WCF?
I would like my operation contract to be:
XElement Query_Post(string query, string [] params);
The best way is to use Stream like Raw HTTP POST with WCF or what you are saying.
The reason is because WCF abstracts all the communication-level physical layout stuff out from the service code. Ideally, you would want to make a service that could turn into SOAP or REST just by flipping the switch.
To support it natively, you probably have to extend WebHttpBinding or make your own binding and implement custom encoder. This is symmetric to the output like the linked post says. You have to twist its arms to get WCF to output non-XML/JSON stuff.
The WCF REST Contrib library enables this functionality:
https://github.com/mikeobrien/WcfRestContrib
It includes a POX formatter and form url encoded formatter and allows you to easily create your own. Formatters are mapped to mime types and automatically selected to serialize/deserialize the entity body based on the content type and accept headers.