silkapp / rest

Packages for defining APIs, running them, generating client code and documentation.
http://silkapp.github.io/rest
390 stars 52 forks source link

More flexible handling of Accept / content types #121

Closed fnoble closed 9 years ago

fnoble commented 9 years ago

I'm still trying to get my head around the Handler / Dict mechanics so forgive me if this is a silly question.

I have a resource that has a representation either as JSON or as a legacy industry specific text based format. The legacy format is stored as a ByteString and is cached by the server. I want to be able to dispatch different responses with these two formats depending on what is in the Accept header. I'm running into a couple problems:

1) I can write a handler for the legacy format that uses fileO. It works but it sets some headers inappropriately for this application. Same with rawXmlO. It doesn't seem like there is any way to have a custom content type?

2) I'm having difficulty combining my jsonO and fileO handlers. I guess I just don't understand the Dict mechanism well enough to see if this is even possible. It seems like it only works for (jsonO . xmlO) because the same value can be serialized into either output? Is there any way to explicitly dispatch based on the Accept header?

hesselink commented 9 years ago

I don't think it's a silly question, and I don't think you're misunderstanding anything. This is just a weak point in rest, that we want to address. We want to make the dictionaries both extensible (so libraries outside rest-core can add new input and output formats, like your legacy format) and make them better composable, so you could do things like your combination of jsonO and fileO.

Currently I think there's no solution for your point 1. There's just no way to set a content-type that's not baked into rest. For point 2, the only thing you could do currently is to have two different handlers.

For further improvements, I think #20 is the issue to follow.

bergmark commented 9 years ago

I'll close this in favor of #20.