I am writing a Padrino app which will expose a few services via REST apis. I need to version the apis. I found this answer which explains how to version an api such that the version is embedded in the uri. I would rather put my version info in the Accept header or some other HTTP header (let's not go into the whole embed-in-uri vs put-in-header debate for now). Is there an idiomatic way of implementing this in a Padrino controller? I would like to avoid littering version checks in all my routes. Is there any way I can put the check in a central place (DRY) or - better still - let Padrino take care of this for me with some magical directives?
Try to implement (ofc, w/o 'v1' in url) this.
Also found that. It should work since Padrino is the little bro of Sinatra.
Can't test for the moment. Please keep me aware !
Related
I'm using Ruby and the Savon gem to interact with SOAP/WS and would like to auto-generate the client request methods from the WSDL in Ruby.
Before I do this, I'd like to know if there's any other Ruby/SOAP library that does this?
Edit: Please note, I already know this isn't available in Savon out the box, in fact my intention is to add in the feature, I'm in the process checking if this exists somewhere else written in Ruby.
Since it's only few days since you asked this question, and I've run into same problem I've decided to create small script to do that.
Download - save as objects.rb for example and run with _bunde exec objects.rb path_to.wsdl_
https://gist.github.com/4622792
Let me know if it works ^^
Take a look at Savon's spec, it has pretty rich testing environment
I think ads_common by Google is relevant to you.
google-api-ads-ruby/ads_common at master ยท googleads/google-api-ads-ruby
rake generate can create the client libraries automatically from WSDL.
It is specialized for Google Ads, but this notion would be helpful to create a versatile client library automatically from WSDL in Ruby.
We're using NewRelic to monitor a Sinatra app. We don't want the probe URL varnish uses to check if the app is online to be instrumented by NewRelic. How do we tell NewRelic to ignore a certain Sinatra route? (The documentation only seems to refer to how to do this in Rails: https://newrelic.com/docs/ruby/blocking-controller-instrumentation)
You could try calling NewRelic::Agent.abort_transaction! within the code path for the probe request. See the API docs for details.
Have you tried what their docs suggest https://newrelic.com/docs/ruby/sinatra-support-in-the-ruby-agent
newrelic_ignore '/ping'
As of version 3.6.3 of the NewRelic gem, you can should be able to use the 'newrelic_ignore' method to ignore endpoints. If you are using Sinatra, you may need to call this class method explicitly, like so:
NewRelic::Agent::Instrumentation::Sinatra::newrelic_ignore('/route/to/ignore')
But, it doesn't work as expected. I am filing a bug report with NewRelic.
What is the best approach to version WebAPIs?
I am building an API from scratch and I would like to ensure that it will version gracefully in the future. I am envisioning something like mysite.com/api/v2/...
One approach I see is to create a separate project (web app) for each version of API. But perhaps there are better ways to do it?
Thank you for your ideas.
Including version number in the URL is the standard approach as I explained in this post (I do not repeat the content): Implementing versioning a RESTful API with WCF or ASP.Net Web Api
You do not need to create a completely new project although you can. The problem that you will be facing with a single project is that there will be collision of names:
/api/v1.0/Car/123
and
/api/v2.0/Car/123
both will point to CarController while you can have only one of those. The solution would be to implement your own IHttpControllerSelector and register with the DependencyResolver. This implementation will look at the version number and perhaps find the type based on the namespace.
UPDATE
I do not intend to start a REST controversy here. But as #DarrelMiller points out, here is an older discussion on the same subject discouraging my suggested approach:
How to version REST URIs
I personally think URL versioning is the way to go.
You will need to create your own implementation of IHttpControllerSelector. The best way is to base this implementation on Microsoft's IHttpControllerSelector. Then you can decide in your IHttpControllerSelectorif you want to version by URL or by content-type.
The most basic implementation directly implements IHttpControllerSelector and just implements the SelectController method but performance reasons it is better to implement some caching around it.
For finding the Controller you simple the IHttpControllerTypeResolver instance you can get using HttpConfiguration.Services.
I've used something like this: http://damsteen.nl/blog/implementing-versioning-in-asp.net-web-api. Also put some code on Github: https://github.com/Sebazzz/SDammann.WebApi.Versioning.
I wrote my own FaceBook library that uses actual Curl requests, not libcurl.
Is there a way to test it? I'm asking this because most solutions involve using something like fakeweb which as far as I can tell will not work here.
The existing code can be found on my github page.
One approach would be to use a different host/port in test mode (eg localhost:12345)
Then in your test run a sinatra or webrick servlet on that port that you configure to respond to the requests your code should be making
You could mock Request.dispatcher with an expected behavior, pretty much like Fakeweb would do.
There are a few examples on this file, specially https://github.com/chrisk/fakeweb/blob/master/lib/fake_web/ext/net_http.rb#L44.
When running your tests/specs, monkey-patch the run method of your Request class to hook into the Marston VCR library. See the existing library_hooks subdir for examples and ideas on how to do this -- the fakeweb implementation is a good place to start.
VCR works well with live services like Facebook's because it captures interactions "as is", and VCRs can be easily re-recorded when the services change.
I'm running into problems with your library, however. You need to require the cgi and json libraries; it also looks like it requires a Rails environment (it's failing to find with_indifferent_access on Hash).
I'm sick of writing out the same controller specs each time I make a new controller. I know I can use the scaffold generator, but there are enough little things I have to change that it usually doesn't save me much time.
Are there any projects/tools out there that provide some sort of base set of specs and/or a DSL to make this easier?
I've never found that any two REST controllers I wanted to write had similar enough interfaces that the tests were at all similar (and generally, I recommend Cucumber, not controller specs).
Something like inherited_resources or Rails 3's respond_with is very useful for writing the controllers, but I'm not sure about the tests.
I use the decent_exposure gem.