search

SpaceApi / validator

A micro-service to validate SpaceAPI endpoints.
Apache License 2.0
2 stars 2 forks source link

Rewrite in golang #38

Closed gidsi closed 4 years ago

gidsi commented 5 years ago

This is a major rewrite of the validator.

Please check the corresponding openapi definition to see changes in the API. You can find it in the openapi.go file in the root folder.

Fixes #32 and #37

rnestler commented 5 years ago

Didn't really look at the code, but this would also need changes to the website right? To use the new API? Couldn't we provide both APIs at the same time?

gidsi commented 5 years ago

Couldn't we provide both APIs at the same time?

We do, nothing needs to be changed :)

We've added the new functionality to the path /v2. The /v1 is basically untouched (error handling has changed, all responses >= 400 are now returning a simple string in the body instead of a json, but that's it).

dbrgn commented 4 years ago

I only skimmed over the sources, but it seems good overall.

We've added the new functionality to the path /v2.

How do we host this? Can Traefik point to different docker containers based on a HTTP request path?

The /v1 is basically untouched (error handling has changed, all responses >= 400 are now returning a simple string in the body instead of a json, but that's it).

In my experience returning JSON objects for errors is always a good idea, since it allows you to add more structured error information later on. Any reason against returning {"message": ...}?

gidsi commented 4 years ago

We've added the new functionality to the path /v2.

How do we host this? Can Traefik point to different docker containers based on a HTTP request path?

It can, right now i've just reimplemented everything v1 does in go too (this file).

I've structured the program so you have different files for the different versions, the main.go provides the http server and serves the different subpath.

The /v1 is basically untouched (error handling has changed, all responses >= 400 are now returning a simple string in the body instead of a json, but that's it).

In my experience returning JSON objects for errors is always a good idea, since it allows you to add more structured error information later on. Any reason against returning {"message": ...}?

I know what you mean, its nice to be able to display additional information and give the whole thing some structure and be able to extend. Unfortunately that just works for a very small amount of errors like "you didn't send proper JSON", everything "unforseen" e.g. a generic 500, 404 or whatsoever will fall back to plain text again (since we don't have that under our control). That means that clients have to implement the body parsing for JSON and the parsing for plain text there (which i don't like since they can't know when to use what).

So i think we should ditch JSON payload in error response and just use plain text in favor of less complexity in every software that will use it.

dbrgn commented 4 years ago

It can, right now i've just reimplemented everything v1 does in go too (this file).

Aah, I see :smile: