I'm implementing access to OAuth service in Play 2.0 application. Generally I'm doing this like described here:
http://www.playframework.com/documentation/2.0.4/ScalaOAuth
Unfortunately the service I'm accessing rejects POST request - which Play sends. Can I change Play's behavior to do GET requests undercover?
Looks like you'll need to write a custom method to handle GET as Play's OAuth object defers request handling to the Commons HTTP library.
Here's a link to the source code for OAuth.scala. Using Play's WS library it should be straightforward to pattern your custom HTTP call based on this:
https://github.com/playframework/playframework/blob/0c265c943a801b2cc9b65e055c956a125f072a64/framework/src/play-ws/src/main/scala/play/api/libs/oauth/OAuth.scala
Related
Newbie question: I have to rebuilt an old REST API, with some clients in Swagger 2.0. Unfortunatly some of the API calls use for HTTP post the following way: For the content it uses the POST body, but for a "sitekey" it use an URL Parameter.
so each post looks something like that:
POST api/update?sitekey=xxx HTTP/1.1
....
{"json": "content"}
I must not ignore the sitekey, so how would i model such a thing in swagger?
If you are using Jax-rs, you can use swagger's #ApiParam annotation. Depending on the jax-rs annotation (#QueryParam, #PathParam, etc.) used along with this annotation, swagger will identify the parameter placement correctly. See here: https://github.com/swagger-api/swagger-core/wiki/Annotations#apiparam
I have been using a .net library to create an oauth session, and submit, modify and cancel orders using the ETRADE api. Now I need to listen for account & order events. As per the ETRADE API documentation, they use CometD & long poling. I did find a .net CometD implementation. However, the ETRADE API docs says that one must pass some oauthHeader to initialize the CometD session. Does anyone know exactly what that oauthHeader is? Any sample code would be appreciated.
I modified to the oauth .net library to provide the same oauth header that gets passed to other API http requests:
public string GetOauthAuthorizationHeader(string url)
{
NameValueCollection headers = _session.Request(_accessToken).Post().ForUrl(url).GetRequestDescription().Headers;
return headers[Parameters.OAuth_Authorization_Header];
}
Passing this header to cometd works. I did have to change to a different .net commetd library (nthachus's commetd.net), though; the one I was previously using was ignoring these headers.
I am building app with Play 2.0.
As far as Play form generator won't generate native http "Delete" request method, it should be replaced with either "Get" or "Post".
#form(routes.Application.delete(id), 'class -> "topRight") {
<input type="submit" value="Delete this computer" class="btn danger">
}
According to Play examples "Post" should be used for "delete" purposes. Though using "Get" is much comfortable as form can be replaced with a simple link (especially having a list of those links on a single page)
So is there any reasons to use POST for emulating DELETE?
The reason to use POST for emulating DELETE instead of GET is because some HTTP verbs (aka methods) are deemed to be safe by the HTTP specification. These methods are HEAD, GET, OPTIONS and TRACE. What this means is there should not be any side effects of application state when making requests using these HTTP methods. Logging, caching, or counter increments are not usually considered application state modification unless it is part of the application domain.
The reason to use POST for emulation of DELETE requests instead of directly using DELETE in a web form is because a number of browsers do not support DELETE directly. Many web frameworks that generate form markup with helpers, like Play and Rails, use the trick you refer to to map the request to the corresponding REST-ish action in the code. See HTTP Method Support in Browsers for more information. Please also see this SO question for more information on this topic. According to the W3C latest candidate recommendation for HTML5, the HTML5 FORM element does not support values for the method attribute other than GET or POST. The same is true for the FORM element in HTML 4.01.
For using non - GET or POST methods you should use JavaScript - for an example jQuery $.ajax() and its type setting.
You can also use Play's javascriptRoutes
Most browsers can't do HTTP requests other than GET or POST from HTML forms, so it's generally emulated using a HTTP POST with an override header or a special form variable.
See Doing a HTTP PUT from a browser
Was after some help on getting started with calling the Rally REST webservice from a .NET MVC webclient.
I've been given the web service info here:
https://rally1.rallydev.com/slm/doc/webservice/
So I can see that I can use a URL to access information from Rally - Similar to:
https://rally1.rallydev.com/slm/webservice/1.39/task?query=((Owner.Name
= owner#blah.com.au) and (State != Completed))&order=Rank&fetch=true&stylesheet=/slm/doc/webservice/browser.xsl
However what I'm not clear on is how to authenticate before making my request?
I'm new to REST web services (have done the SOAP/WSDL awhile back) - so it doesn't seem like with REST you're supposed to add a reference to something to get client classes created? Is this correct? That you just create a HTTPRequest using a URI - and make the call, getting back a HTTPResponse (which I can hopefully do something with).
A lot of examples seem to have specific service/api classes that they're calling methods on or accessing properties - so I'm not sure if that's because they're using SOAP rather than REST - or that they created them themselves.
Maybe I'm looking at the wrong documentation as it seems assumed you know how to be authenticated. Or I'm missing a reference?
I know the question is old, but this might help someone else. You need to pass a Basic Authentication header with your base64-encoded username and password as part of your get() request. I found this information on an Atlassian documentation page and successfully applied it with Rally API 3.0 (should also work with 2.0). So in your get() request, include a header similar to the following:
auth_header = 'Authorization : Basic ' + base64_encode('username:password')
We'd like to add some integration tests for the many REST services that our Grails app exposes, instead of manually verifying them using the Firefox Poster plugin that we are currently using.
BTW, In our case it HAS to be an integration test, not a unit test.
I trust others have gone thru' this before and could save us some time instead of experimenting...
`grails test-app -integration`
Does the above command actually launch the functionality required to do a self-post to our own app (http://localhost/myapp) ? It would have to go through the url mapping pipeline, xml content negotiation, spring/acegi security, etc. If so, I suppose we could use the Groovy RESTClient as documented here:
http://groovy.codehaus.org/modules/http-builder/doc/rest.html
Google tells me another option is the functional-testing plugin:
http://thediscoblog.com/2009/06/15/grails-hip-tip-testing-restful-services/
Any comments or issues from the experienced? It's a Grails 1.2.1 app using plugins.acegi=0.5.2
What you want is
grails test-app integration:
As per http://grails.org/doc/latest/ref/Command%20Line/test-app.html
The REST services are usually created via actions in a controller that are set in the URLMappings to work with the different HTTP methods (GET, PUT, POST, DELETE), so since they are simple actions in a controller an integration test can be just a test method that test the action like any other, sending them the content-type you need, JSON for example and passing the correct data as JSON if that is what your services is expecting.
You can create multiple test methods for the same action to test the difference responses, for example if a non valid resource is requested than test that the service is returning the correct error code 404 for instance.