Closed aeden closed 11 years ago
I would use HTTP Accept headers, I have a wd-sinatra branch that will read the accept header and pass the format to params[:format]
. So you just set the Accept header to application/xml
or application/json
and the params[:format] will come back with :json
or :xml
and then you in your service implementation you can check params[:format] and serialize or render different objects accordingly.
That sounds like a good idea, my only question is when do you mutate the params object? We need to make sure that's safe, can't be exploited and won't mess up with the params verification.
Sorry still traveling and not giving all your great work enough attention, but please know I'm really grateful for all you've done so far. On May 9, 2013 2:03 PM, "Jack Chu" notifications@github.com wrote:
I would use HTTP Accept headers, I have a wd-sinatra branchhttps://github.com/kamui/wd-sinatra/commit/5afb5f227ae24dbb6c28ddb9e5d5361c838a456dthat will read the accept header and pass the format to params[:format]. So you just set the Accept header to application/xml or application/json and the params[:format] will come back with :json or :xmland then you in your service implementation you can check params[:format] and serialize or render different objects accordingly.
— Reply to this email directly or view it on GitHubhttps://github.com/mattetti/Weasel-Diesel/issues/6#issuecomment-17660965 .
Yep, I agree with not mutating params. I also questioned it on this issue. I mostly did it because the branch was sort of a proof of concept for using the Accept header and rack-accept and I knew params would get passed from middleware to the service implementation.
Re: Traveling, no problem. I've been building an API in Sinatra over the last year and while I enjoyed it, there were some pain points and I liked the direction you went with WD. I really want to use it for my next API platform, so anything I can do to help out and make it more usable.
The first thing I should do when getting online is to make you a contributor. For things like accept params I think we should use the env instead of the params. On May 9, 2013 3:18 PM, "Jack Chu" notifications@github.com wrote:
Yep, I agree with not mutating params. I also questioned it on this issuehttps://github.com/mattetti/wd-sinatra/issues/14. I mostly did it because the branch was sort of a proof of concept for using the Accept header and rack-accept and I knew params would get passed from middleware to the service implementation.
Re: Traveling, no problem. I've been building an API in Sinatra over the last year and while I enjoyed it, there were some pain points and I liked the direction you went with WD. I really want to use it for my next API platform, so anything I can do to help out and make it more usable.
— Reply to this email directly or view it on GitHubhttps://github.com/mattetti/Weasel-Diesel/issues/6#issuecomment-17663640 .
Sounds good :thumbsup:
env
works for me, what should the key be? Maybe wd.format
?
Sounds perfect On May 10, 2013 12:00 AM, "Jack Chu" notifications@github.com wrote:
Sounds good [image: :thumbsup:]
env works for me, what should the key be? Maybe wd.content_type?
— Reply to this email directly or view it on GitHubhttps://github.com/mattetti/Weasel-Diesel/issues/6#issuecomment-17692720 .
If my service produces both XML and JSON, how do I determine which to render in the service implementation?