Non-POST statics

[abbradar]

statics are supposed to be POST-only according to the tutorial, so there is no way for a resource to specify, e.g., GET /count (returns total number of items). Of course I can just use POST but this seems unRESTful to me. An improvement might be to specify method in the schema, like this:

...
  , R.schema = noListing $ named [ ("clear", static POST Clear)
                                 , ("count", static GET Count)
                                 ]
...

This looks better since statics are supposed to be CRUD-unrelated and can be closer to any method depending on what they actually do. I don't know the difficulty of improvement like this, though, maybe with current architecture this is hard.

Anyway, maybe I've just missed some easy method to accomplish this?

[hesselink]

Sorry for the delay. No, I don't think we currently have something for this, and it seems like we probably should. We have actions and selects on top of an identified resource, but at the top level we only have static for actions, but nothing matching selects.

Regarding the implementation, it would probably be more symmetrical to implement it in the same way as statics currently is. That means adding a staticSelect :: aid -> Endpoint mid sid aid schema, adding a field staticSelects :: aid -> Handler m to Resource and adding the proper routing.

Here I'm reusing the action identifier, but I now doubt that will work: it means each identifier needs both an action and a select associated with it, where generally you have only one: Count doesn't have an action, and something like Signout doesn't have a select. But adding another identifier to the Resource seems like quite a large breaking change for this. @bergmark What do you think?

[bergmark]

Can this be solved by using a singleton resource instead? If so we could perhaps even remove the aid and create helpers for easily adding these singletons for this use case.

If we add a new type variable for GET, will we later need to add even more for DELETE and others? Seems like this would get nasty quickly...

[hesselink]

You mean making count its own singleton subresource? I don't think that would work, subresources live on top of identified resources, so instead of /foo/count, you'd get /foo/id/1/count.

I can't see a need for DELETE as a static; what would that mean? But I also think even the three identifiers are too much, and it would be good if we could get rid of the aid at least, instead of adding another.

[bergmark]

Oh, right...

Would it be possible to hide these details under a statics field in the resource instead of specifying it for the resource itself?

[hesselink]

What do you mean exactly?

[fnoble]

+1, I would also like to see GET on statics

[hesselink]

@fnoble Could you describe your use case?

[fnoble]

The same as @abbradar, I have some endpoints that are outside of just CRUD on a single resource. Basically it takes some parameters and returns something computed from the resources.