It's still a WIP. Right now there is only one thing jumping to the forefront of my mind is that the POST request param handling is a little clumsy -- it's a little ugly to have to parse the request body explicitly to extract the params instead of just having them readily available.
The other thing that will help is to just have copious documentation written as if idiots are reading it. :)
That's all Crystal/Athena powered through the entire stack below the browser.
Mostly now I am just writing React to make interaction nice, and writing pieces of API to deliver the data.
@[ART::Post(path: "")]
@[ART::View(status: :created)]
@[ART::ParamConverter("article", converter: Blog::Converters::RequestBody, model: Blog::Models::Article)]
def new_article(article : Blog::Models::Article) : Blog::Models::Article
article.save
article
endmodel: named argument in the annotation that specifies what type it should try to deserialize the data into
In a lot of my cases, there is nothing directly applicable from the DB. It's a set of params being provided by the UI that lets the API find the right data, but the params and the data being returned don't have any direct relationship.
So in the screenshot example, there is a set of criteria from a panel unseen to the left that lets one select the type of data, date ranges, amount of data, etc... Those are all bundled into a set of params to feed to the API . The API goes and finds information for the requested server(s), of the requested type and timeframe.
There is no correspondence between the params and specific database models, and I'm not returning serialized class model data in the response, either. Rather, it's a minimized, trimmed subset of that data.
def get_data(request : HTTP::Request) : JSON::Any
raise ART::Exceptions::BadRequest.new "Missing request body." unless body = request.body
JSON.parse body
end