Aggregate Approvals in Malawi

Hi everyone,

The Malawi team is planning to begin backend work related to https://openlmis.atlassian.net/browse/MW-57 soon. The few implementation details mentioned in the epic may be off – we didn’t realize that the core product’s support for extension modules allows for the ad hoc addition of new endpoints. The planned functionality described by the epic is accurate, though.

My question for the group is whether this is functionality the core project would like to incorporate and maintain. Assuming it were implemented to the standard expected by the core project, would a pull-request for this functionality be approved even though it covers only a small subset of the potential features related to aggregated approvals? Part of the discussion in the “New Feature Request from Malawi” section here mentions that “there are additional core requirements that need definition and need to be addressed for this feature set to be acceptable.” On the other hand, it sounds as though a definitive decision wasn’t reached.

I was encouraged to post here, and hope it’s the right venue. I’d be glad to instead post in the Product Committee forum if it’s more appropriate.

Thank you,

Ben

Hi Ben,

When I encouraged this, the thought was that the endpoints and functionality that this new Service might provide:

https://github.com/OpenLMIS/mw-openlmis-requisition

Might actually be appropriate, more expedient and more performant if built directly into the Requisition Service. Put another way, maybe the new endpoints that the Malawi team were going to put into the mw-openlmis-requisition service, were so un-controvisial and so simple to support within the Requisition service, that the tech committee would be in wild agreement to add them and the Requisition Service team members would be glad to see a PR for them.

To be in wild agreement, we first need a rough idea of what this new endpoint(s) would be. mw-openlmis-requisition doesn’t have anything yet, so if the Malawi team could outline, in simple text in this forum:

  1. New endpoints. That is the new RESTful Resources or new representations.

  2. Draft outline of what the JSON schema would be.

This forum could quickly weigh in if the path would lead to wild agreement before any code was written.

And as you mentioned, even if the Requisition Service didn’t desire the PR, architecturally and performance wise it could make quite a bit of sense to use an Extension module. Lets cross that bridge if we need to.

Best,

Josh

···

On Apr 20, 2017, at 6:16 PM, > benleibert@gmail.com wrote:

Hi everyone,

The Malawi team is planning to begin backend work related to
https://openlmis.atlassian.net/browse/MW-57
soon. The few implementation details mentioned in the epic may be off – we didn’t realize that the core product’s support for extension modules allows for the ad hoc addition of new endpoints. The planned functionality described by the epic is accurate, though.

My question for the group is whether this is functionality the core project would like to incorporate and maintain. Assuming it were implemented to the standard expected by the core project, would a pull-request for this functionality be approved even though it covers only a small subset of the potential features related to aggregated approvals? Part of the discussion in the “New Feature Request from Malawi” section here
mentions that “there are additional core requirements that need definition and need to be addressed for this feature set to be acceptable.” On the other hand, it sounds as though a definitive decision wasn’t reached.

I was encouraged to post here, and hope it’s the right venue. I’d be glad to instead post in the Product Committee forum if it’s more appropriate.

Thank you,

Ben

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/f56f359f-bc1d-4cea-a39c-572f86959734%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hi Josh,

Thank you very much for your quick response. Your thoughts and questions about our needs for extending the API make a lot of sense. Although we haven’t yet determined exactly what the new endpoints will look like, we’ll follow up as soon as we have.

Thanks again!

~ Ben

Hi Josh,

Thanks yet again for your guidance with this. We propose a /requisitions/approve and /requisitions/save endpoint, each of which Sebastian has documented here:

https://github.com/OpenLMIS/openlmis-requisition/blob/proposed-endpoints/src/main/resources/api-definition.yaml

Please don’t hesitate to let me know if there’s anything else we can do to help gauge the core-team’s interest.

Kind regards,

Ben

Hey Ben,

These new API endpoints with their JSON schemas look fine to me; I expect the core team would incorporate them into the Requisition Service.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongsun.ahn@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

···

On Apr 27, 2017, at 2:02 PM, > benleibert@gmail.com wrote:

Hi Josh,

Thanks yet again for your guidance with this. We propose a /requisitions/approve and /requisitions/save endpoint, each of which Sebastian has documented here:

https://github.com/OpenLMIS/openlmis-requisition/blob/proposed-endpoints/src/main/resources/api-definition.yaml

Please don’t hesitate to let me know if there’s anything else we can do to help gauge the core-team’s interest.

Kind regards,

Ben

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/394a1c4a-4d2f-434d-bf7e-e0715f9651f6%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Hi Chongsun,

That’s great to hear. We’re eager to continue contributing to the core project, and I’m glad that this can be another opportunity. Thank you very much for letting me know!

Kind regards,

Ben

Hello everyone,

  We have started the work on those batch endpoints and will be providing a pull request to the core OpenLMIS soon. We have also briefly discussed the new endpoints at the technical comittee call today. We have put some thought into the proper "partial success" HTTP code that we want to use. Since the endpoints we are considering are operating on several instances, the actions on some of them may succeed, while for some other they may fail. This will be reflected in the response body by having two arrays - one containing successfully processed requisitions and another containing errors connected with specific requisitions. Other than the response body though, what should be the HTTP code? There seemed to be 3 main ideas:

   - Always **200**       - No matter if all requisition actions succeeded or only some of them, the response would be 200. The errors (if any) would be found in the response body.

  ****- **400** if at least one failed, **200**       if all succeeded - if there's at least one entry in the errors array, the response code would be 400. If all succeeded, it would be 200.

   - **207**       (multi-status) which is not an official HTTP response code, but it's in the WebDAV extension to the HTTP protocol.

  We are currently leaning towards the first option - always returning 200. Returning 400 on partial success may suggest that the whole request failed, which would not be the case. We also don't think that using 207 would really benefit us much - we would still need to go to the response body to figure out what happened with the request.

  Does anyone else have a strong opinion on this or want to propose another approach? We want to follow the same standard for any other batch operations that may appear in OpenLMIS, therefore this decision will impact all future batch endpoints as well and will be documented in the code style guide.

Best regards,

  Sebastian.

···


      Sebastian Brudziński

    Software Developer / Team Leader

SolDevelo Sp. z o. o. [LLC]

     Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98  81-451, Gdynia

     [http://www.soldevelo.com](http://www.SolDevelo.com)

               Place of registration: Regional Court for the City of Gdansk            KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,            Share capital: 60,000.00 PLN

sbrudzinski@soldevelo.com

Would it not be easier to program to option #2?

If I am writing a client, I want to know if there are errors, so any non-200 response would be easier for me to know if there was an error vs having to read each (200) message, then write some additional logic. Or will you have numbers in the message?

···


Sebastian Brudziński

Software Developer / Team Leader

SolDevelo Sp. z o. o. [LLC]

Office: +48 58 782 45 40/ Fax: +48 58 782 45 41Al. Zwycięstwa 96/9881-451, Gdynia

http://www.soldevelo.com

Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,Share capital: 60,000.00 PLN

sbrudzinski@soldevelo.com

openlmis-dev+unsubscribe@googlegroups.com

openlmis-dev@googlegroups.com

https://groups.google.com/d/msgid/openlmis-dev/4a363e19-1dff-44cd-01c3-cc0cdbce2e97%40soldevelo.com

https://groups.google.com/d/optout

Similar dilemma me and Chongsun had while working at this ticket. The issue then was: what should be the http response if user is created but email was not send to that user? For that time we ended up with: 200 and log warn if email was not sent. I’m wondering if introduce 207 status code to openlmis, during work at batch endpoints, wouldn’t be helpful also to some other cases like that I mentioned.

···

On Tuesday, May 9, 2017 at 5:57:29 PM UTC+2, Sebastian Brudziński wrote:

Hello everyone,

  We have started the work on those batch endpoints and will be providing a pull request to the core OpenLMIS soon. We have also briefly discussed the new endpoints at the technical comittee call today. We have put some thought into the proper "partial success" HTTP code that we want to use. Since the endpoints we are considering are operating on several instances, the actions on some of them may succeed, while for some other they may fail. This will be reflected in the response body by having two arrays - one containing successfully processed requisitions and another containing errors connected with specific requisitions. Other than the response body though, what should be the HTTP code? There seemed to be 3 main ideas:

   - Always **200**       - No matter if all requisition actions succeeded or only some of them, the response would be 200. The errors (if any) would be found in the response body.

  ****- **400** if at least one failed, **200**       if all succeeded - if there's at least one entry in the errors array, the response code would be 400. If all succeeded, it would be 200.

   - **207**       (multi-status) which is not an official HTTP response code, but it's in the WebDAV extension to the HTTP protocol.



  We are currently leaning towards the first option - always returning 200. Returning 400 on partial success may suggest that the whole request failed, which would not be the case. We also don't think that using 207 would really benefit us much - we would still need to go to the response body to figure out what happened with the request.
  Does anyone else have a strong opinion on this or want to propose another approach? We want to follow the same standard for any other batch operations that may appear in OpenLMIS, therefore this decision will impact all future batch endpoints as well and will be documented in the code style guide.

Best regards,

  Sebastian.

On 01.05.2017 19:49, Chongsun Ahn wrote:

Hey Ben,

    These new API endpoints with their JSON schemas look fine to me; I expect the core team would incorporate them into the Requisition Service.


                Shalom,

                Chongsun

                ​

                -- ​

                There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

  •                      Software Development Engineer*
    

Village****Reach* ** Starting at the Last Mile*

                    2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: ** 1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** **and our Blog

On Apr 27, 2017, at 2:02 PM, > > > ...@gmail.com wrote:

Hi Josh,

              Thanks yet again for your guidance with this. We propose a **                  /requisitions/approve** and **/requisitions/save**                   endpoint, each of which Sebastian has documented here:

https://github.com/OpenLMIS/openlmis-requisition/blob/proposed-endpoints/src/main/resources/api-definition.yaml

              Please don't hesitate to let me know if there's anything else we can do to help gauge the core-team's interest.

Kind regards,

Ben

          You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

          To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

          To post to this group, send email to
         ...@googlegroups.com.

          To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/394a1c4a-4d2f-434d-bf7e-e0715f9651f6%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/394a1c4a-4d2f-434d-bf7e-e0715f9651f6%40googlegroups.com?utm_medium=email&utm_source=footer).

          For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

  You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

  To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

  To post to this group, send email to openlm...@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/CB44C260-9E87-45BF-B6F6-C2A14894BD50%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/CB44C260-9E87-45BF-B6F6-C2A14894BD50%40villagereach.org?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


      Sebastian Brudziński

    Software Developer / Team Leader


     sbrud...@soldevelo.com

SolDevelo Sp. z o. o. [LLC]

     Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98  81-451, Gdynia


     [http://www.soldevelo.com](http://www.SolDevelo.com)



               Place of registration: Regional Court for the City of Gdansk            KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,            Share capital: 60,000.00 PLN

The more I think about this, the more I like 400.

Reasoning:

  • We generally have full control over what the server sends, and what the client does with the response. That makes it easy for us to adopt something like 207 and attach our meaning to it, however having full control over producer/consumer doesn’t really lend itself to good adoption reasoning if we want to fully leverage the standard. e.g. if some other client used our RESTful HTTP endpoints, and got a 207, there’s nothing they could inherently know about that 207 that would fit with what we meant by it - other than “it’s a mixed bag bub". We’d just be expanding the litany of statuses our clients would need to understand, needlessly (why comes next).
  • 400 lets the client know explicitly that the operation shouldn’t be tried again, without the client changing the request. The semantics of this will be especially important when handling the “non-idempotent” POST /requisitions/approve in the example. This request, if tried again without alteration, could move some of the requisitions which were approved successfully in the first call, to be approved again (and move supervisory node again) in a second followup request that was un-altered. Or if the supervision structure didn’t have more supervisory nodes or the user didn’t have the approval right on both nodes, it might result in new errors in the followup request that the first didn’t have. Weather the request is POST or PUT, we don’t want clients blindly re-trying, and 400 means that every-time.
  • 200 doesn’t have this explicit statement about re-trying. Case closed. This bullet point is here because bullet points are nicer in multiples of threes…

So my vote is more firmly on the 400 side.

As a side note, I wonder about using the POST in /requisitions/approve. While returning a 400 for this operation is explicit to a client that it shouldn’t be tried again un-altered, what makes it explicit to the client that it shouldn’t be re-tried if it times out? Re-trying as the client without an explicit status code could lead to exactly the same situation(s) I ruminated on above. It could become a PUT operation - though I think that would likely increase the verbosity of the representation. An alternative that might be good-enough to that extra work could be to be very explicit in the documentation (RAML) that this endpoint should never be re-tried if it times out. A blink** tag might do it.

Josh

···

On May 9, 2017, at 8:44 PM, Paweł Albecki gidgnulur@gmail.com wrote:

Similar dilemma me and Chongsun had while working at
this ticket
. The issue then was: what should be the http response if user is created but email was not send to that user? For that time we ended up with: 200 and log warn if email was not sent. I’m wondering if introduce 207 status code to openlmis, during work at batch endpoints, wouldn’t be helpful also to some other cases like that I mentioned.

On Tuesday, May 9, 2017 at 5:57:29 PM UTC+2, Sebastian Brudziński wrote:

Hello everyone,

We have started the work on those batch endpoints and will be providing a pull request to the core OpenLMIS soon. We have also briefly discussed the new endpoints at the technical comittee call today. We have put some thought into the proper “partial success” HTTP code that we want to use. Since the endpoints we are considering are operating on several instances, the actions on some of them may succeed, while for some other they may fail. This will be reflected in the response body by having two arrays - one containing successfully processed requisitions and another containing errors connected with specific requisitions. Other than the response body though, what should be the HTTP code? There seemed to be 3 main ideas:

  • Always 200 - No matter if all requisition actions succeeded or only some of them, the response would be 200. The errors (if any) would be found in the response body.

****- 400 if at least one failed, 200
if all succeeded - if there’s at least one entry in the errors array, the response code would be 400. If all succeeded, it would be 200.

  • 207 (multi-status) which is not an official HTTP response code, but it’s in the WebDAV extension to the HTTP protocol.

We are currently leaning towards the first option - always returning 200. Returning 400 on partial success may suggest that the whole request failed, which would not be the case. We also don’t think that using 207 would really benefit us much - we would still need to go to the response body to figure out what happened with the request.

Does anyone else have a strong opinion on this or want to propose another approach? We want to follow the same standard for any other batch operations that may appear in OpenLMIS, therefore this decision will impact all future batch endpoints as well and will be documented in the code style guide.

Best regards,

Sebastian.

On 01.05.2017 19:49, Chongsun Ahn wrote:

Hey Ben,

These new API endpoints with their JSON schemas look fine to me; I expect the core team would incorporate them into the Requisition Service.

Shalom,

Chongsun

– ​

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Apr 27, 2017, at 2:02 PM, > > > > ...@gmail.com wrote:

Hi Josh,

Thanks yet again for your guidance with this. We propose a /requisitions/approve and /requisitions/save endpoint, each of which Sebastian has documented here:

https://github.com/OpenLMIS/openlmis-requisition/blob/proposed-endpoints/src/main/resources/api-definition.yaml

Please don’t hesitate to let me know if there’s anything else we can do to help gauge the core-team’s interest.

Kind regards,

Ben

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev...@googlegroups.com.

To post to this group, send email to
...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/394a1c4a-4d2f-434d-bf7e-e0715f9651f6%40googlegroups.com
.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openlmis-dev...@googlegroups.com.

To post to this group, send email to
openlm...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CB44C260-9E87-45BF-B6F6-C2A14894BD50%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.



Sebastian Brudziński

Software Developer / Team Leader

sbrud...@soldevelo.com

SolDevelo Sp. z o. o. [LLC]

Office: +48 58 782 45 40
/ Fax: +48 58 782 45 41
Al. Zwycięstwa 96/98
81-451, Gdynia

http://www.soldevelo.com

Place of registration: Regional Court for the City of Gdansk
KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,
Share capital: 60,000.00 PLN

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/d5fda07d-dbe2-489f-8507-edf20eb40624%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

I’d second Josh’s logic for a 400 error

If I were a tea pot trying to batch order coffee from multiple sources, I’d like to know I need to change something (and I should pay attention) — a 200 error means I can stop paying attention and assume all is well…

···

Nick Reid | nick.reid@villagereach.org

Friendly Neighborhood Spiderman, Information Systems Group

VillageReach** *** Starting at the Last Mile
*2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

CELL: +1.510.410.0020

SKYPE: nickdotreid

www.villagereach.org


From: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Josh Zamor josh.zamor@villagereach.org

Sent: Tuesday, May 9, 2017 1:13 PM

To: Paweł Albecki

Cc: OpenLMIS Dev

Subject: Re: [openlmis-dev] Aggregate Approvals in Malawi

The more I think about this, the more I like 400.

Reasoning:

  • We generally have full control over what the server sends, and what the client does with the response. That makes it easy for us to adopt something like 207 and attach our meaning to it, however having full control over producer/consumer doesn’t really lend itself to good adoption reasoning if we want to fully leverage the standard. e.g. if some other client used our RESTful HTTP endpoints, and got a 207, there’s nothing they could inherently know about that 207 that would fit with what we meant by it - other than “it’s a mixed bag bub". We’d just be expanding the litany of statuses our clients would need to understand, needlessly (why comes next).
  • 400 lets the client know explicitly that the operation shouldn’t be tried again, without the client changing the request. The semantics of this will be especially important when handling the “non-idempotent” POST /requisitions/approve in the example. This request, if tried again without alteration, could move some of the requisitions which were approved successfully in the first call, to be approved again (and move supervisory node again) in a second followup request that was un-altered. Or if the supervision structure didn’t have more supervisory nodes or the user didn’t have the approval right on both nodes, it might result in new errors in the followup request that the first didn’t have. Weather the request is POST or PUT, we don’t want clients blindly re-trying, and 400 means that every-time.
  • 200 doesn’t have this explicit statement about re-trying. Case closed. This bullet point is here because bullet points are nicer in multiples of threes…

So my vote is more firmly on the 400 side.

As a side note, I wonder about using the POST in /requisitions/approve. While returning a 400 for this operation is explicit to a client that it shouldn’t be tried again un-altered, what makes it explicit to the client that it shouldn’t be re-tried if it times out? Re-trying as the client without an explicit status code could lead to exactly the same situation(s) I ruminated on above. It could become a PUT operation - though I think that would likely increase the verbosity of the representation. An alternative that might be good-enough to that extra work could be to be very explicit in the documentation (RAML) that this endpoint should never be re-tried if it times out. A blink** tag might do it.

Josh

On May 9, 2017, at 8:44 PM, Paweł Albecki gidgnulur@gmail.com wrote:

Similar dilemma me and Chongsun had while working at
this ticket
. The issue then was: what should be the http response if user is created but email was not send to that user? For that time we ended up with: 200 and log warn if email was not sent. I’m wondering if introduce 207 status code to openlmis, during work at batch endpoints, wouldn’t be helpful also to some other cases like that I mentioned.

On Tuesday, May 9, 2017 at 5:57:29 PM UTC+2, Sebastian Brudziński wrote:

Hello everyone,

We have started the work on those batch endpoints and will be providing a pull request to the core OpenLMIS soon. We have also briefly discussed the new endpoints at the technical comittee call today. We have put some thought into the proper “partial success” HTTP code that we want to use. Since the endpoints we are considering are operating on several instances, the actions on some of them may succeed, while for some other they may fail. This will be reflected in the response body by having two arrays - one containing successfully processed requisitions and another containing errors connected with specific requisitions. Other than the response body though, what should be the HTTP code? There seemed to be 3 main ideas:

  • Always 200 - No matter if all requisition actions succeeded or only some of them, the response would be 200. The errors (if any) would be found in the response body.

****- 400 if at least one failed, 200
if all succeeded - if there’s at least one entry in the errors array, the response code would be 400. If all succeeded, it would be 200.

  • 207 (multi-status) which is not an official HTTP response code, but it’s in the WebDAV extension to the HTTP protocol.

We are currently leaning towards the first option - always returning 200. Returning 400 on partial success may suggest that the whole request failed, which would not be the case. We also don’t think that using 207 would really benefit us much - we would still need to go to the response body to figure out what happened with the request.

Does anyone else have a strong opinion on this or want to propose another approach? We want to follow the same standard for any other batch operations that may appear in OpenLMIS, therefore this decision will impact all future batch endpoints as well and will be documented in the code style guide.

Best regards,

Sebastian.

On 01.05.2017 19:49, Chongsun Ahn wrote:

Hey Ben,

These new API endpoints with their JSON schemas look fine to me; I expect the core team would incorporate them into the Requisition Service.

Shalom,

Chongsun

There are 10 kinds of people in this world; those who understand binary, and those who don’t.

Chongsun Ahn | chongs...@villagereach.org

Software Development Engineer

Village****Reach* ** Starting at the Last Mile*

2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: **1.206.910.0973 FAX: 1.206.860.6972

SKYPE: chongsun.ahn.vr

www.villagereach.org

Connect on Facebook****, Twitter** ** and our Blog

On Apr 27, 2017, at 2:02 PM,
...@gmail.com wrote:

Hi Josh,

Thanks yet again for your guidance with this. We propose a /requisitions/approve and /requisitions/save endpoint, each of which Sebastian has documented here:

https://github.com/OpenLMIS/openlmis-requisition/blob/proposed-endpoints/src/main/resources/api-definition.yaml

Please don’t hesitate to let me know if there’s anything else we can do to help gauge the core-team’s interest.

Kind regards,

Ben

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to
...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/394a1c4a-4d2f-434d-bf7e-e0715f9651f6%40googlegroups.com
.

For more options, visit
https://groups.google.com/d/optout
.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

To post to this group, send email to
openlm...@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/CB44C260-9E87-45BF-B6F6-C2A14894BD50%40villagereach.org
.

For more options, visit
https://groups.google.com/d/optout
.



Sebastian Brudziński

Software Developer / Team Leader

sbrud...@soldevelo.com

SolDevelo Sp. z o. o. [LLC]

Office: +48 58 782 45 40
/ Fax: +48 58 782 45 41
Al. Zwycięstwa 96/98
81-451, Gdynia

http://www.soldevelo.com

Place of registration: Regional Court for the City of Gdansk
KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,
Share capital: 60,000.00 PLN

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/d5fda07d-dbe2-489f-8507-edf20eb40624%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

You received this message because you are subscribed to the Google Groups “OpenLMIS Dev” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/openlmis-dev/ED288D46-147B-44CD-A71F-48BB7D28925F%40villagereach.org
.

For more options, visit https://groups.google.com/d/optout.

I don’t have a strong opinion, but I’m more on the side of 400 as well.

  One side questions though, what type of validations errors will users usually face at this point?

Regards,

Paweł
···

On 11.05.2017 08:45, Nick Reid wrote:

I’d second Josh’s logic for a 400 error

      If I were a tea pot trying to batch order coffee from multiple sources, I'd like to know I need to change something (and I should pay attention) — a 200 error means I can stop paying attention and assume all is well....

** Nick Reid** | nick.reid@villagereach.org

              *                  Friendly Neighborhood <strike>Spiderman</strike>, Information Systems Group*

VillageReach** *** Starting at the Last Mile

             *                   2900 Eastlake Ave. E, Suite 230, Seattle, WA 98102, USA

                              CELL: +1.510.410.0020

                                SKYPE: nickdotreid

              [www.villagereach.org](http://www.villagereach.org/)

From:

           on behalf of Josh Zamor Tuesday, May 9, 2017 1:13 PM Paweł Albecki OpenLMIS Dev Re: [openlmis-dev] Aggregate Approvals in Malawi

The more I think about this, the more I like 400.

Reasoning:

  •               We generally have full control over what the server sends, and what the client does with the response.  That makes it easy for us to adopt something like 207 and attach *our*                   meaning to it, however having full control over producer/consumer doesn’t really lend itself to good adoption reasoning if we want to fully leverage the standard.  e.g.  if some other client used our RESTful HTTP endpoints, and got a 207, there’s nothing they could inherently know about that 207 that would fit with what we meant by it - other than “it’s a mixed bag bub".  We’d just be expanding the litany of statuses our clients would need to understand, needlessly (why comes next).
    
  •               400 lets the client know explicitly that the operation shouldn’t be tried again, without the client changing the request.  The semantics of this will be especially important when handling the "non-idempotent" POST /requisitions/approve in the example.  This request, if tried again without alteration, could move some of the requisitions which were approved successfully in the first call, to be approved again (and move supervisory node again) in a second followup request that was un-altered.  Or if the supervision structure didn’t have more supervisory nodes or the user didn’t have the approval right on both nodes, it might result in new errors in the followup request that the first didn’t have.  Weather the request is POST or PUT, we don’t want clients blindly re-trying, and 400 means that every-time.
    
  •               200 doesn’t have this explicit statement about re-trying.  Case closed.  This bullet point is here because bullet points are nicer in multiples of threes...
    

So my vote is more firmly on the 400 side.

          As a side note, I wonder about using the POST in /requisitions/approve.  While returning a 400 for this operation is explicit to a client that it shouldn’t be tried again un-altered, what makes it explicit to the client that it shouldn’t be re-tried if it times out?  Re-trying as the client without an explicit status code could lead to exactly the same situation(s) I ruminated on above.  It could become a PUT operation - though I think that would likely increase the verbosity of the representation.  An alternative that might be good-enough to that extra work could be to be very explicit in the documentation (RAML) that this endpoint should never be re-tried if it times out.  A [blink](https://www.google.pl/search?q=blink&ie=utf-8&oe=utf-8&gws_rd=cr&ei=rSESWbv6MIf7swH2oYmwDQ#q=blink+html)**tag might do it.

Josh

                On May 9, 2017, at 8:44 PM, Paweł Albecki <gidgnulur@gmail.com                    > wrote:
                  Similar dilemma me and Chongsun had while working at [
                    this ticket](https://openlmis.atlassian.net/browse/OLMIS-1977)                      . The issue then was: what should be the http response if user is created but email was not send to that user? For that time we ended up with: 200 and log warn if email was not sent. I'm wondering if introduce 207 status code to openlmis, during work at batch endpoints, wouldn't be helpful also to some other cases like that I mentioned.



                  On Tuesday, May 9, 2017 at 5:57:29 PM UTC+2, Sebastian Brudziński wrote:

Hello everyone,

                        We have started the work on those batch endpoints and will be providing a pull request to the core OpenLMIS soon. We have also briefly discussed the new endpoints at the technical comittee call today. We have put some thought into the proper "partial success" HTTP code that we want to use. Since the endpoints we are considering are operating on several instances, the actions on some of them may succeed, while for some other they may fail. This will be reflected in the response body by having two arrays - one containing successfully processed requisitions and another containing errors connected with specific requisitions. Other than the response body though, what should be the HTTP code? There seemed to be 3 main ideas:

                         - Always **200**                             - No matter if all requisition actions succeeded or only some of them, the response would be 200. The errors (if any) would be found in the response body.

                        ****- **400**                             if at least one failed, **200**
                        if all succeeded - if there's at least one entry in the errors array, the response code would be 400. If all succeeded, it would be 200.

                         - **207**                             (multi-status) which is not an official HTTP response code, but it's in the WebDAV extension to the HTTP protocol.



                        We are currently leaning towards the first option - always returning 200. Returning 400 on partial success may suggest that the whole request failed, which would not be the case. We also don't think that using 207 would really benefit us much - we would still need to go to the response body to figure out what happened with the request.
                        Does anyone else have a strong opinion on this or want to propose another approach? We want to follow the same standard for any other batch operations that may appear in OpenLMIS, therefore this decision will impact all future batch endpoints as well and will be documented in the code style guide.

Best regards,

                        Sebastian.

On 01.05.2017 19:49, Chongsun Ahn wrote:

Hey Ben,

                          These new API endpoints with their JSON schemas look fine to me; I expect the core team would incorporate them into the Requisition Service.


                                      Shalom,

                                      Chongsun



                                      --

                                      There are 10 kinds of people in this world; those who understand binary, and those who don’t.
                                          Chongsun Ahn | chongs...@villagereach.org
  •                                            Software Development Engineer*
    

Village****Reach* ** Starting at the Last Mile*

                                          2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

DIRECT: 1.206.512.1536 **CELL: ** 1.206.910.0973 FAX: 1.206.860.6972

                                          SKYPE: chongsun.ahn.vr

www.villagereach.org

                                          Connect on **[Facebook](https://www.facebook.com/pages/VillageReach/103205113922)****,** **[Twitter](https://twitter.com/VillageReach)**** **                                              and our **[Blog](http://villagereach.org/see-our-blog/thoughts-from-the-last-mile/)**
                                On Apr 27, 2017, at 2:02 PM,
                                  ...@gmail.com wrote:

Hi Josh,

                                    Thanks yet again for your guidance with this. We propose a **                                        /requisitions/approve** and **                                        /requisitions/save**                                         endpoint, each of which Sebastian has documented here:

https://github.com/OpenLMIS/openlmis-requisition/blob/proposed-endpoints/src/main/resources/api-definition.yaml

                                    Please don't hesitate to let me know if there's anything else we can do to help gauge the core-team's interest.

Kind regards,

Ben

                                You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

                                To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

                                To post to this group, send email to
                                  ...@googlegroups.com.

                                To view this discussion on the web visit [
                                  https://groups.google.com/d/msgid/openlmis-dev/394a1c4a-4d2f-434d-bf7e-e0715f9651f6%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/394a1c4a-4d2f-434d-bf7e-e0715f9651f6%40googlegroups.com?utm_medium=email&utm_source=footer).

                                For more options, visit [
                                  https://groups.google.com/d/optout](https://groups.google.com/d/optout).

                        You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

                        To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.

                        To post to this group, send email to
                          openlm...@googlegroups.com.

                        To view this discussion on the web visit [
                          https://groups.google.com/d/msgid/openlmis-dev/CB44C260-9E87-45BF-B6F6-C2A14894BD50%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/CB44C260-9E87-45BF-B6F6-C2A14894BD50%40villagereach.org?utm_medium=email&utm_source=footer).

                        For more options, visit [
                          https://groups.google.com/d/optout](https://groups.google.com/d/optout).



Sebastian Brudziński

                                                          Software Developer / Team Leader


                          sbrud...@soldevelo.com
                            SolDevelo Sp. z o. o. [LLC]


                          Office:                                 +48 58 782 45 40
                                                          / Fax: +48 58 782 45 41
                                                          Al. Zwycięstwa 96/98
                                                          81-451, Gdynia


                          [http://www.soldevelo.com](http://www.soldevelo.com/)



                                                          Place of registration: Regional Court for the City of Gdansk
                                                          KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,
                                                          Share capital: 60,000.00 PLN

                You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

                To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

                To post to this group, send email to
                  openlmis-dev@googlegroups.com.

                To view this discussion on the web visit [

https://groups.google.com/d/msgid/openlmis-dev/d5fda07d-dbe2-489f-8507-edf20eb40624%40googlegroups.com](https://groups.google.com/d/msgid/openlmis-dev/d5fda07d-dbe2-489f-8507-edf20eb40624%40googlegroups.com?utm_medium=email&utm_source=footer).

                For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

        You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

        To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

        To post to this group, send email to
          openlmis-dev@googlegroups.com.

        To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/ED288D46-147B-44CD-A71F-48BB7D28925F%40villagereach.org](https://groups.google.com/d/msgid/openlmis-dev/ED288D46-147B-44CD-A71F-48BB7D28925F%40villagereach.org?utm_medium=email&utm_source=footer).

        For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

  You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.

  To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev+unsubscribe@googlegroups.com.

  To post to this group, send email to openlmis-dev@googlegroups.com.

  To view this discussion on the web visit [https://groups.google.com/d/msgid/openlmis-dev/MWHPR02MB32299895DD577C014065254294ED0%40MWHPR02MB3229.namprd02.prod.outlook.com](https://groups.google.com/d/msgid/openlmis-dev/MWHPR02MB32299895DD577C014065254294ED0%40MWHPR02MB3229.namprd02.prod.outlook.com?utm_medium=email&utm_source=footer).

  For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).


Paweł Gesek

    Technical Project Manager

      / +48 690 020 875

SolDevelo Sp. z o. o. [LLC]

     Office:  +48 58 782 45 40 / Fax:  +48 58 782 45 41  Al. Zwycięstwa 96/98  81-451, Gdynia

     [http://www.soldevelo.com](http://www.SolDevelo.com)

               Place of registration: Regional Court for the City of Gdansk            KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585,            Share capital: 60,000.00 PLN

openlmis-dev@googlegroups.comopenlmis-dev@googlegroups.comjosh.zamor@villagereach.org
Sent:
To:
Cc:
**Subject:**pgesek@soldevelo.com