You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is just a request for design review regarding HTTP status codes returned by the services when the wrapped service yields a code other than 200, as discussed on today's call.
Currently if a wrapped service (e.g. tnrs/ot/resolve) returns a 400 or other non-200 HTTP status code, the phylotastic service returns a 200, with a payload that contains a status_code field giving the wrapped service's status code.
An alternative design, which might be seen as simpler for clients (one check instead of two) and better in line with the HTTP spec, would be to have the phylotastic service return the same status code (with some exceptions) as the wrapped service. The payload could be the same as at present.
There could be exceptions in cases where phylotastic 'knows better' than the wrapped service, e.g. because it has successfully compensated for a bug in the wrapped service.
The text was updated successfully, but these errors were encountered:
@jar398 , I have started to work on this issue for all phylotastic web services. I will also include additional parameters for some web services to improve the functionality. Based on that, the structure of results for those services may change. Please give me couple of days to finish this. I will update the current documentation with more info (new params, example results, error codes, capacity) and let you know. Thanks.
No urgency from my point of view. I’m just filing design issues as I see them, and have no opinion (in my current role) as to whether they should be acted upon.
Please note that I have not pushed the changes to the server yet. So trying the examples in this doc will not work at this moment. Please have a look at the doc and give me your suggestions (if anything needs to be changed or added) before I push the modified codes. Thanks.
This is just a request for design review regarding HTTP status codes returned by the services when the wrapped service yields a code other than 200, as discussed on today's call.
Currently if a wrapped service (e.g.
tnrs/ot/resolve
) returns a 400 or other non-200 HTTP status code, the phylotastic service returns a 200, with a payload that contains astatus_code
field giving the wrapped service's status code.An alternative design, which might be seen as simpler for clients (one check instead of two) and better in line with the HTTP spec, would be to have the phylotastic service return the same status code (with some exceptions) as the wrapped service. The payload could be the same as at present.
There could be exceptions in cases where phylotastic 'knows better' than the wrapped service, e.g. because it has successfully compensated for a bug in the wrapped service.
The text was updated successfully, but these errors were encountered: