provide endpoints in the form of service/endpoint instead of service.endpoint about encore HOT 6 CLOSED

What about dealing with REST API? It's more common to have a pattern likeGET /api/{resourceName}/{deepPath}. I mean... this still works, but feel strange at first. I'm not sure if this framework should be used for public API if I wanna follow the REST API's principles.

from encore.

Thanks so much @darkLord19, @sopta, @abtris for the thoughtful feedback provided here.
We've just added support for this with Encore v0.16.2: https://github.com/encoredev/encore/releases/tag/v0.16.2

Please give it a whirl and let us know what you think!

from encore.

Hi @darkLord19, thanks for posting. Is there a particular use case you have in mind? Or is it for aesthetic reasons?

from encore.

Yeah, that's a good point, I agree we should offer better support for creating REST APIs.

from encore.

That would be awesome. I primarily work with REST API and GraphQL and this type of URL endpoints it's not what you seek. Also, it depends on the purpose of this project, I guess. Either it could be used only for microservice services (not an endpoint for mobile API gateway) or support both ways.

I can see a similarity with controller/action (presenter/action) approach from web frameworks. It's a behavior of a default routing system.

Something like this:

package users

type Params struct {
    ID int `param:"int"`  // it could be converted by encore automatically (string -> int) .. or implicit by using tags 
}

type Response struct {
    Message string
}

//encore:rest public
func Orders(ctx context.Context, params *Params) (*Response, error) {
   msg := fmt.Sprintf("get user's orders ID: ", params.ID)
   return &Response{Message: msg}, nil
}

// GET localhost:8080/api/users/45/orders .. instead of GET /api/users.Orders?id=5

from encore.

I think define how path will show should be configuration option to override URL package.name format. Similar as @sopta mention. I just will be careful about implicit conversions (go isn't java ;-))

Add more flexibility will be great.

API Spec languages support URI Template variable and will be great if we can use it.

from encore.