--
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/f56f359f-bc1d-4cea-a39c-572f86959734%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/394a1c4a-4d2f-434d-bf7e-e0715f9651f6%40googlegroups.com.
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.
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
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 GdanskKRS: 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...@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/4a363e19-1dff-44cd-01c3-cc0cdbce2e97%40soldevelo.com.
Hey Ben,
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:
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/d5fda07d-dbe2-489f-8507-edf20eb40624%40googlegroups.com.
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....
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
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?
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/MWHPR02MB32299895DD577C014065254294ED0%40MWHPR02MB3229.namprd02.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.