API skeleton for revel new cmd

[hfeeki]

I think a pure json rest api server will be needed by many user.
And a fake api server also needed.

[robfig]

Can you provide (more of) an example of what you're thinking of?

[hfeeki]

More and more web site need support restful api for developer, so I think maybe those web site project should be split into api server and ui server , like next:
api server <-- json restful api --> ui server
api server <-- json restful api --> other site, mobile app, etc.

So the developing flow is:
json restful api -> api server -> ui server

In order to develop api server and ui server in the same time, a fake api server should be a good idea.

[hfeeki]

The api server do not need public directory, maybe do not need templates, do not need to know html, css, javascript, ajax, It will better for integration test, performance test, etc.

[brendensoares]

@hfeeki so you want a way to create a Revel app from the command line that does not use HTML templates or public assets and that simply returns JSON/XML/etc serialized responses based on model structs and their validation rules with a RESTful GET/POST/PUT/PATCH/DELETE approach?

It seems to me that this is already quite possible. Just create a new app with no templates or static public assets.

It seems we would want to do some things to generate scaffolded routes, controller classes and model structs based on a database schema to automate the monotonous/repetitive steps to initial setup. Perhaps that is waht you're really asking?

@robfig Do we have enough information here to mark this as contributor ready?

[TeemoWan]

http://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api

[brendensoares]

@wanli2011 I've always enjoyed that article ever since I found it. REST can be a very controversial topic when it comes to "best practice". Anything specific you from this article you want to discuss?

As far as this request goes, I can see some value in having some resource generation similar to rails for models, views, controllers, etc.

Does anyone else have any input or insight on this?

[iamjem]

I think this would be an excellent feature. Some way to easily generate scaffolding would be very cool. Maybe providing various struct types that people could combine to compose API controllers. I don't know that this could be totally automated, there would have to be some explicit work in regard to data, since Revel really has no opinion in regard to models and data. Users would at least have to implement the code to perform the CRUD operations, since someone could be using any number of things.. the database/sql package, an ORM like Gorp, or some NoSQL solution.

[brendensoares]

@iamjem standard models are a must for this feature to be implemented since you can't do much of an API without having CRUD access to data somewhere.

We've discussed the options, but Go is different that other web capable languages in how data can be modeled, extended and serialized.

There are also competing ideas of what the "Go way" of doing data abstraction is. For example, many Gophers strongly dislike the idea of ORM due to the object/relational mismatches that inevitably occur when interfacing the two. That, though, leads to a very sadistic/purist approach of working at a low level with the data (e.g. pure SQL queries) instead of gaining the benefits of abstraction.

For commentary on the topic, you may enjoy http://blog.codinghorror.com/object-relational-mapping-is-the-vietnam-of-computer-science/

There is still value here in this feature request, but we need to discuss it more and make a decision on how to approach data modeling in Revel first. I've tagged this issue accordingly.

[iamjem]

My comment was more that an API in Revel doesn't need to be responsible for the CRUD operations, or know any specifics about the data layer of the application period. Instead its job could just be sanitizing and validating incoming and outgoing data. Maybe it just provides the hooks for the user to implement CRUD operations, handing them a neat bundle of "clean" data to work from.

Revel certainly needs to know what the data should look like, and thats where I think there's some opportunities. It would make sense to evaluate how popular data packages in Go are handling modeling so that Revel could follow closely in line, allowing users to potentially re-use parts of the models they're already creating.

[brendensoares]

Revel will provide the CRUD actions in the controller, right?

One big issue is that because there are different data abstraction packages in common use, there is no single approach to support. The most generic is simply using structs to contain model data. Beyond that, we have to choose one way over the others.

[eddiejaoude]

One big issue is that because there are different data abstraction packages

It could start by supporting the most commonly used approach, then expanded afterwards.

This feature would be useful for rapid development & to kickstart a project.

[brendensoares]

@eddiejaoude I agree it would be useful at reducing the effort needed to get a project off the ground. Let's explore this more in v0.13.

[eddiejaoude]

@brendensoares sounds good.

It could start by supporting the most commonly used approach, then expanded afterwards.

If not the most commonly, may be the recommended approach?

[brendensoares]

@eddiejaoude Check out v0.14 of The New Roadmap.

[eddiejaoude]

Add models folder to revel/revel/skeleton
Choose official Revel ORM (e.g. STORM)
Add model/controller generation

👍

[PatrickWolleb]

Could you give me a starting point on where to implement such a thing? I have been trying to build a REST API around revel. I think we need global errors (or better anything) rendered as JSON or any data type supported by the API. I.e controller.RenderError should know what type to render based on content-type.. I am not sure how to approach but it would be great to help develop a solution.

[PatrickWolleb]

How can I pass RenderArgs to the controller?

[brendensoares]

Check out progress on this topic here: https://github.com/kishorevaishnav/revelgen

[brendensoares]

@PatrickWolleb feel free to join us on IRC to ask any questions.

Where are you trying to pass RenderArgs from?

As far as detecting content type per request, I think that's a good idea and deserves its own issue: #778.

[jniltinho]

Gojsonschema

Description
An implementation of JSON Schema, based on IETF's draft v4 - Go language

https://github.com/xeipuuv/gojsonschema

[brendensoares]

@jniltinho that's a nice tool ,but we can't include that in the scope of Revel itself.

TODO

• define requirements
• implement

Requirements (WIP)

• create and run api app with no errors
• no template file watching

Tests (WIP)

1. revel new apitest skeleton=api
2. revel run apitest
3. no errors
4. ...

[notzippy]

Should be re-assigned to revel/cmd enhancement

[pedromorgan]

Maybe RAML fits in here also #968

[notzippy]

Closed and moved to revel/cmd revel/cmd#73