REST server skeleton

[davidhunterxyz]

@alkchr What do you think about a JSON REST server skeleton in Goal?

[ghost]

@DavidHunter I'm all for it. Are there any specific requirements (the way it should look like at al)?

[davidhunterxyz]

I think it should be similar to Tiger Tonic and follow guidelines from this blog post Best Practices for Designing a Pragmatic RESTful API. Swagger is also something interesting to look into.

[ghost]

@DavidHunter So what exactly Goal is missing right now?

1. Reading of JSON from request body.
2. Writing of JSON to the response.
3. Better routing.
4. Auto documentation of the API (easy to implement and useful).

Anything else? How do you see the implementation of these features? Any ideas?

P.S.: I haven't looked closely at swagger yet. Will do it.

[davidhunterxyz]

@alkchr I think the things you mentioned cover everything needed as a start. Then someone can create a new API server with

goal rest github.com/$username/$project

[davidhunterxyz]

@alkchr I think we should focus on getting the web server to production ready

[ghost]

@DavidHunter I'd like to discuss routing first. Currently, routes is a regular Go package. Advantages of this approach:

• No need for a new syntax, Golang is used.
• It's possible to split routes between multiple files.
• Autocomplete in editors and IDEs.

There are a few other approaches that could be applied:

• Revel like routes file (but with yaml or any other syntax instead of custom one).
• "Annotation" before every action. In Bottle.py it looks as follows:

@route('/hello/<name>')
def index(name):
    return template('<b>Hello {{name}}</b>!', name=name)

The last one is my favourite. Though there are no annotations in Go, that's why our version would look more like (not type safe):

// @GET /hello/:name
func (c App) Greet(name string) http.Handler {
    c.Context = name
    return c.Render()
}

What do you think? How the list of routes should look like (go package vs. conf file vs. "annotations")?

When we are done with routes we'll have to implement reverse routing.

I think we should focus on getting the web server to production ready

@DavidHunter You mean the production readiness of the API server? Any specific steps to achieve that? What should we pay attention to?

[davidhunterxyz]

@alkchr I mean production ready of github.com/colegion/goal/internal/skeleton Since their are plans to change organization name and etc.

[ghost]

Oh, I see.

[ghost]

Closing for now as there are no specific actionable items. Routing, auto documentation, etc. need their own issues.