2017. január 26., csütörtök 7:37:49 UTC+1 időpontban JohnGB a következőt 
írta:
>
> Since it is an HTTP Api, what about returning a standard HTTP status line, 
>> maybe with some non standard status code) and additional details about the 
>> error in the response body, JSON encoded?
>
>
> That is exactly what we do.  We return a HTTP status, but in addition, we 
> return a JSON encoded body with our internal status code, and description.  
>
> The question is more about the cleanest and easiest way to maintain this 
> as the HTTP status is determined by our internal status code (which is far 
> more fine grained than what we can achieve with only a HTTP status).  I'm 
> trying to find the cleanest way to implement a reference to our internal 
> status code so that we can also extract the other information (i.e. HTTP 
> status, and description) from our status code.
>
> On 25 January 2017 at 19:09, Manlio Perillo <manlio....@gmail.com 
> <javascript:>> wrote:
>
>> Il giorno mercoledì 25 gennaio 2017 18:16:33 UTC+1, JohnGB ha scritto:
>>>
>>> I have an HTTP API written in Go, and to give more fine grained 
>>> responses to the client app, we return our own error codes along with the 
>>> standard HTTP status codes  Along a similar line to what Twitter does 
>>> with its error codes 
>>> <https://dev.twitter.com/overview/api/response-codes>.
>>>
>>
>> Since it is an HTTP Api, what about returning a standard HTTP status 
>> line, maybe with some non standard status code) and additional details 
>> about the error in the response body, JSON encoded?
>>
>> > [...]
>>
>> Regards
>> Manlio
>>
>> -- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/golang-nuts/VzDfhN4GtIY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
A map is easier to extend in less coupled places than a switch, but may 
hide and cause problems if used unsparingly 
(use it in init() functions and through an exported Register method, only). 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to