Hi, Shyamal,
Just to make sure, do you mean you want the response body including
something like `_herf` or `links` to other resources?
```json
{
"id" : 1,
"body" : "My first blog post",
"postdate" : "2015-05-30T21:41:12.650Z",
"_links" : {
"self": { "href": "http://blog.example.com/posts/1"; },
"comments": { "href": "http://blog.example.com/posts/1/comments";,
"totalcount" : 20 },
"tags": { "href": "http://blog.example.com/posts/1/tags"; }
}
}
```
Best Regards!
@ Zhiyuan Ju <https://github.com/juzhiyuan>
Shyamal Madura Chinthaka <[email protected]> 于2021年7月27日周二 上午2:36写道：
> Hi Team,
>
> +1 to rely on HTTP status code instead of the code in the response body.
>
> This will take our burden of enforcing governance to define/maintain
> additional code in the response body which will unlikely to effectively
> override the HTTP status code.
>
> However - if possible - enriching the response of these APIs to adopt
> HATEOAS would be progressive immensely.
>
>
> Regards,
> Shyamal
>
> On Mon, Jul 26, 2021, 07:20 Zhiyuan Ju <[email protected]> wrote:
>
> > Hi,
> >
> > Users have 2 ways to use our product: Using Dashboard or Call API
> directly.
> >
> > We have JSONSchema checker on the backend, if users call API directly and
> > check failed, it will return the JSONSchema error; if users use
> Dashboard,
> > why not validate data on Web? So I think there has no need to add a
> > specific login code in the Response Body :)
> >
> > Best Regards!
> > @ Zhiyuan Ju <https://github.com/juzhiyuan>
> >
> >
> > Chao Zhang <[email protected]> 于2021年7月26日周一 上午9:41写道：
> >
> > > HTTP status code will be fine if we don’t care the very specific error
> > > type.
> > >
> > > Chao Zhang
> > > https://github.com/tokers
> > >
> > > On July 25, 2021 at 17:34:40, Jintao Zhang ([email protected])
> > > wrote:
> > >
> > > I agree!
> > > At the same time, I also think that HTTP Status code should be used
> > instead
> > > of the logical code field.
> > >
> > > Zhiyuan Ju <[email protected]> 于2021年7月25日周日 下午3:29写道：
> > >
> > > > Hi,
> > > >
> > > > Any further discussion on this mail? I'm going to list all APIs and
> > check
> > > > which part we should modify.
> > > >
> > > > Best Regards!
> > > > @ Zhiyuan Ju <https://github.com/juzhiyuan>
> > > >
> > > >
> > > > Zhiyuan Ju <[email protected]> 于2021年7月22日周四 下午2:47写道：
> > > >
> > > > > I would prefer relying on Status Code instead of `code` (actually
> > it's
> > > a
> > > > > manual logical and extendable code).
> > > > >
> > > > > Why not list all API cases then have a choice?
> > > > >
> > > > > Best Regards!
> > > > > @ Zhiyuan Ju <https://github.com/juzhiyuan>
> > > > >
> > > > >
> > > > > Ming Wen <[email protected]> 于2021年7月22日周四 下午12:36写道：
> > > > >
> > > > >> please give an example about i18n for a better understanding
> > > > >>
> > > > >> Thanks,
> > > > >> Ming Wen, Apache APISIX PMC Chair
> > > > >> Twitter: _WenMing
> > > > >>
> > > > >>
> > > > >> JunXu Chen <[email protected]> 于2021年7月22日周四 上午11:36写道：
> > > > >>
> > > > >> > Agree +1
> > > > >> >
> > > > >> >
> > > > >> > I think we still need to keep the `code` field.
> > > > >> >
> > > > >> > The FE needs to implement i18n according to it.
> > > > >> >
> > > > >> > Unless `message` is semantic and can be used as a key of i18n.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Thu, 22 Jul 2021 at 00:02, Ming Wen <[email protected]>
> > wrote:
> > > > >> >
> > > > >> > > I don't think the `code` filed is useful, HTTP response code
> is
> > > > >> enough.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Ming Wen, Apache APISIX PMC Chair
> > > > >> > > Twitter: _WenMing
> > > > >> > >
> > > > >> > >
> > > > >> > > Peter Zhu <[email protected]> 于2021年7月21日周三 下午11:18写道：
> > > > >> > >
> > > > >> > > > Agree +1.
> > > > >> > > > And I think we should maintain the `code` filed and maintain
> > the
> > > > >> doc of
> > > > >> > > > API.
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
