Hacker News Reader

Comment by seliopou | Hacker News Reader

I interrupted my reading at 'Accept and respond with JSON' to write this comment, before I skipped over that section and returned to reading the rest.

Folks that aren't aware of Webmachine should take a look:

https://github.com/webmachine/webmachine

The 'Accept' header should determine the response type, but content negotiation is something that few bother to implement. Webmachine does that for you, among other things like choosing the correct status code for your response.

Also, shameless plug for my OCaml port:

https://github.com/inhabitedtype/ocaml-webmachine

View on HN

> Webmachine is an application layer that adds HTTP semantic awareness on top of the excellent bit-pushing and HTTP syntax-management provided by mochiweb, and provides a simple and clean way to connect that to your application's behavior.

Great buzzwords, I have no idea what this project actually does.

I think its about adding semantic web stuff for mochiweb servers in their response? After clicking through a couple links I'm still not quite sure what it does.

What is the usefulness of this feature?

The only advantage I see is that your clients can choose the format they want to work with, but since the serialization format is just a message format that has no impact on the code, and that most of them have a bijective transformation between them, I don't see the point.

If it feels like a lot of work (Or the added complexity of a moving part, if using the tool you linked) for next to no impact.

things like this are useful if you have a user that is integrating your api into some kind of legacy application that does not support json. Then in the future when JSON goes out of style, you could easily add support whatever the new format is.

If you don't care about others using your API, then don't do it. If you do, follow the standard which says you SHOULD have a Content-Type if there is a body to your response.

My comment was about whether it's worth supporting multiple values for the "Accept" header, not the "Content-Type" header.

I've read through the README and links and still have no idea what webmachine does.

Django REST Framework has this built in, and is very easy to turn on. I always turn it on even though my users almost exclusively use json. I had one user use xml once, because they didnt know how to use json in whatever it was they were using. Noone has ever used yaml, but i leave it there just in case.

if you do it right, using the standard html content type returns a human browseable representation of your api with forms for posts and whatnot.

Omg I love the browsable api of Django. I am searching for something similar for .NET - any pointers anyone?

https://swagger.io/tools/swagger-ui/ :)

That's not browsable. Swagger is just a prefilled Postman. I mean some UI where I can navigate and discover the resources directly.

> The 'Accept' header should determine the response type

Also, the HTTP decision diagram: https://github.com/for-GET/http-decision-diagram/tree/master...

Reply on news.ycombinator.com