Response code for POST method should be 201 not 200

[jannyHou]

Response code for POST method should be 201 not 200

An old issue from LoopBack3: strongloop/loopback#360

We should fix it in LoopBack4 as well.

Notes from the spike

• Users should be able to customize the status code from the response object returned by the controller method, otherwise we should default to 201 - this will be implemented by Configurable response types/formats #436.

• There are two approaches we can choose as implementation, but based on the spike findings and the consensus, pursue option 1 from below:

  • option 1: return the status code and header from the result of controller method directly
  • option 2: read the status code from OpenAPI spec and write it into the response in rest/src/writer.ts, see the spike PR [don't merge]poc: customize statusCode using response spec #1260
  • There is already some comparison and discussion for the two approaches in PR [don't merge]poc: customize statusCode using response spec #1260 to start with, chose one approach and implement it.

Acceptance criteria

• Modify controllers in the example/* projects so that create* methods (typically mapped to POST verb) return 201 Created instead of `200.
  • Update the OpenAPI Spec description of operation result, replace 200 to 201
  • Update the controller method implementation to return status code 201 and set Location header to the URL where the newly created model instance can be found
• Update CRUD Controller template used by CLI similarly
• If Extension: CrudRestController #2736 has been done, then update the extension accordingly too.

[Cooker-Monster]

Thanks to reactivate this important point !

[bajtos]

I think this has two parts:

• We need to figure out how to allow controllers to specify response status code (and response headers, while we are at this)

• The CRUD controller template (see [CLI] Generate Controller with CRUD methods #727) and the CRUD controller base class (see [WIP] [RFC] feat: Add REST mapping for repository interfaces #740) should return 201 from create operation

[jannyHou]

hi team, we are upgrading from swagger2 to openapi3, PR is ready for it #916
There is an interface change of the responseObject in openapi3, I think it's better to implement this story for v3 directly instead of implement it with v2 then take another effort to upgrade to v3, thanks!

[kjdelisle]

Does the alteration to the responseObject formatting change the logic required to handle the return code in some way? I would've expected that the sequence would simply handle the success of a POST with a 201 code in the same way for v2 and v3; that is, I'd expect a property with the same name (probably statusCode) at the top level.

[jannyHou]

@kjdelisle good point, honestly I am not sure, and due to the effort needed in v2-v3, see comment:#753 (comment), the PR won't be landed in a few days, so no sense to block this story :)

[bajtos]

@kjdelisle and me decided this does not really belong to MVP/Walking Skeleton.

[Cooker-Monster]

So, can you give a status of this issue please ? can we expect a fix on 4.x ?
whatever the version of Open Api specification, have a correct code for POST still make sense ;-)
But I'm not at the right position to mesure the effort... so it's easy to ask !

[kjdelisle]

Marking the item as non-MVP doesn't mean that we won't be doing it for the 4.x release, it just means that it's not a part of our initial push to get the framework into a stable state.

Our goal with the idea of MVP is that we want the framework to be in a position where:

• Community members can begin learning how it works in earnest
• Community members can begin to contribute fixes, as well as new features or plugins

The MVP is not the final release! It's an interim state between the constant flux of alpha and the near-completeness of a beta. We've set this goal to help stop us from getting too far ahead of ourselves with respect to what we want to see in the final release vs. what should be there at a minimum.

[Cooker-Monster]

Ok fine ! thx

[Cooker-Monster]

Hi, any news on this topic please ?

[jannyHou]

@Cooker-Monster checking with my team, will let you know the update then.

[dhmlau]

@jannyHou , you've mentioned that this is related to the openapi-v3 work that you're doing. Could you please add more details? Thanks.

[dhmlau]

Seems to be a duplicate of #436.

[bajtos]

Definitely not a duplicate. We may need #436 to be implemented first before we can return 201 with a Location header.

I am removing this story from GA and moving it to [EPIC] REST layer improvements (post-GA) #1452

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[lajosf]

Dear @bajtos , as I can see the "stale bot" gonna close this thread, because there is no activity. As I can see it is still a problem, not solved yet and may effect more developers.

[bajtos]

@lajosf I am afraid we don't have enough bandwidth to implement this feature soon. Would you like to contribute it yourself?

[lajosf]

Dear Bajtos,
Thank you for the quick answer! After I wrote the above comment I made workaround and works fine.
I have no option to contribute, but thank you (one half of my life is reserved by the company, the other is by my family :))!

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.