megaease/easemesh

The response data type of the management interface is not uniform

pengjiejason opened this issue · 6 comments

pengjiejason commented

I found that the responset type in mesh is divided into about 4 kinds.
I think the first one is normal, so I have tried to list as many interfaces as possible for the last three.

  1. Headers: Content-Type: application/json. The return data is also json. Most api's return this way.
  2. Headers: Content-Type: text/plain; charset=utf-8. The return data is json.
    • /apis/v1/mesh/traffictargets
    • /apis/v1/mesh/customresources
    • /apis/v1/mesh/httproutegroups
  3. Headers: Content-Type: text/vnd.yaml. The return data is yaml.
    • /apis/v1/objects/easemesh-controller
  4. Headers: Content-Type: text/plain; charset=utf-8. The return data is yaml.
    • apis response status is 40X. eg: /apis/v1/mesh/traffictargets/nameNotExist
localvar commented

Yes, the 1st one is the correct way.

The 2nd: it is a bug, we have set the 'Content-Type' to 'application/json' in the code, but it is not working. I will fix it.
The 3rd: we have to keep it as it is, the mesh APIs return JSON and the Easegress APIs return YAML by default, and this is an Easegress one.
The 4th: as the status code is not 2XX and the body is empty, all APIs haven't set the content type, can we just ignore it?

zhao-kun commented

About 4th, I agree @pengjiejason , we need to uniform content-type settings.

zhao-kun commented

I think we need to clarify our API contract:

  • API for the EaseMesh should set Content-Type: application/json no matter the status code is 2XX or others.
  • API for the Easegress should set Content-Type: text/vnd.yaml no matter the status code is 2XX or others.
  • Path start with /apis/v1/mesh is an API for the EaseMesh.
  • Path start with /apis/v1/objects is an API for the Easegress.
localvar commented

For non-2XX responses, theoretically, it is possible that the request hasn't been processed by our code, so I think the client should not be so strict on them.

zhao-kun commented

Yes, the request hasn't been processed the Content-type can be undefined, but if the request has been processed, sever should return Content-Type in a consistent way (it's doesn't matter with the client, it's the server's behavior, the server's behavior should be consistency).

localvar commented

the 2nd issue has been fixed in PR easegress-io/easegress#430.
the 4th is a little complex and needs more time to fix.