Need a way to return 201 Created as the result of a PUT

[Porges]

Per RFC7321:

If the target resource does not have a current representation and the
PUT successfully creates one, then the origin server MUST inform the
user agent by sending a 201 (Created) response. If the target
resource does have a current representation and that representation
is successfully modified in accordance with the state of the enclosed
representation, then the origin server MUST send either a 200 (OK) or
a 204 (No Content) response to indicate successful completion of the
request.

At the moment 200 OK (or 204 No Content) is always returned. It would be nice to have a way to indicate that a resource was created.

[jkarni]

Closing this as a duplicate of #190 . For people who might come across is, currently the suggested way about it is defining your own combinator, with a HasServer instance that differs from the current one only in having 201 rather than 200 as the status code.

[i-am-the-slime]

I tried to backtrack to the actual solution but couldn't really find anything. Can you go into more detail about this "own combinator" approach? Thanks!

[alpmestan]

@i-am-the-slime Hi! This PR changed all existing HTTP method combinators to be simple type synonyms of Verb with different parameters. You can use this to define your own Post that returns something else than 200 by defining a new type synonym similar to servant's default Post but specifying another status code than 200. You need servant from git for now though to be able to use that as this will only be part of the next release.

[i-am-the-slime]

Ah, I'm using stack. I'll probably wait for the next LTS including this then and just return a 200 in any case.

[alpmestan]

You can use packages from git repos with stack as well, FWIW: http://docs.haskellstack.org/en/stable/yaml_configuration/ (scroll down a bit and look for "git")

[rvion]

eg:

resolver: lts-5.5

# Local packages, usually specified by relative directory name
packages:
- .
- location:
    git: git@github.com:haskell-servant/servant.git
    commit: 5188e842a9288ac3986b30b93cb1a5d58cb2933d
  extra-dep: true
  subdirs:
  - servant
  - servant-blaze
  - servant-cassava
  - servant-client
  - servant-docs
  - servant-examples
  - servant-foreign
  - servant-js
  - servant-lucid
  - servant-mock
  - servant-server

[LeifW]

I don't see how hardcoding a response code into the type signature addresses the issue, which quotes the RFC as saying either a 201 or 204 should be returned, depending on if the update target already exists.