New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support CRUD via a REST API #346

Open
disko opened this Issue Nov 22, 2014 · 9 comments

Comments

Projects
None yet
5 participants
@disko
Copy link
Member

disko commented Nov 22, 2014

This still needs to be discussed in detail. However, Kotti does very well as a backend for single page and mobile applications.

See http://blog.startifact.com/posts/better-rest-with-morepath-08.html for some ideas / insightful thoughts on REST API best practices.

@msabramo

This comment has been minimized.

Copy link
Contributor

msabramo commented Jan 24, 2015

I'll look at the blog post and upload PR #385 ...

@umeboshi2

This comment has been minimized.

Copy link
Contributor

umeboshi2 commented Jan 24, 2015

I'm glad y'all are thinking about doing this. I have been using cornice for some of my stuff and it is very good, but it is strictly url dispatch.
I have also been looking at pyramid royal for traversal and it seems pretty good, but haven't had time to actually try it out. The docs need work and the example is using mogodb instead of sqlalchemy, but it's already hooked to pyramid and looks useful.

Just thought I'd share my +2 cents.

@disko

This comment has been minimized.

Copy link
Member

disko commented Jan 26, 2015

I'll look at the blog post and upload PR #385 ...

great - you're welcome to open a thread on the mailinglist or join us on irc://irc.freenode.net/#kotti for any discussion.

@disko

This comment has been minimized.

Copy link
Member

disko commented Jan 26, 2015

I'm glad y'all are thinking about doing this.

Yes, this is probably my top priority for the upcoming versions of Kotti.

I have been using cornice for some of my stuff and it is very good, but it is strictly url dispatch.

Same here – I really like Cornice but it doesn't match well with Kotti / traversal. As we do already have Colander schemata for the views in Kotti, we might very well "reuse" those for validation of REST PUT/PUSH requests.

@umeboshi2

This comment has been minimized.

Copy link
Contributor

umeboshi2 commented Jan 26, 2015

That's why I mentioned royal, although I haven't looked at it yet. When I started shifting to app style pages, I made use of colander and dropped deform. I'm using bootstrap and backbone.validation on the client side for the forms. I don't think cornice will ever do traversal (I think I remember reading that there is a wontfix bug concerning this). I'm glad that the move to REST is a top priority. I really want to use Kotti as a plugin, so I can focus on other things. Good Luck! Let me know if you need anything. :)

@jcerjak

This comment has been minimized.

Copy link
Contributor

jcerjak commented Feb 5, 2015

We're using rest toolkit in a project, seems to be working ok. Not sure how well it would fit Kotti and traversal though. Here is a comparison with other frameworks: http://rest-toolkit.readthedocs.org/en/latest/comparison.html

@umeboshi2

This comment has been minimized.

Copy link
Contributor

umeboshi2 commented Oct 9, 2015

Has anybody done any work with this? I have started messing around and just used the json renderer and a bit of code to create views that may help as a start:

https://github.com/umeboshi2/ittok/blob/master/ittok/views/view.py

I have noticed that there is a lot of work being done in the renderer, that could be done in the view, or another middleman. It might be better for an object to be created from a view that can be either passed to a template, or sent as json to the client. Client side rendering is a big bonus that saves a lot of resources on the server.

I made it so that my javascript and css is served through fanstatic, but it seems that the need() is on a per "view" basis, instead of a per "object" basis, even though the view can be set per object. While playing around and getting things started, I noticed that repoze.workflow has changed, and y'all should take the "eval" out of views/edit/init.py. Also, filedepot FileStorage needs to implement .list() method.

@tiberiuichim

This comment has been minimized.

Copy link
Contributor

tiberiuichim commented Oct 9, 2015

@umeboshi2: There's this PR for the json views, still a work in progress #452

And this branch for the repoze.workflow upgrade ( a work in progress until we figure some things out, like how to automatically tranform strings into i18n messages from zcml). https://github.com/cruxlog/kotti/tree/upgrade_repozeworkflow

@umeboshi2

This comment has been minimized.

Copy link
Contributor

umeboshi2 commented Oct 10, 2015

Thanks! I integrated the views in my code to play with them. I couldn't get the views to respond when sending ACCEPT='application/vnd.api+json', no matter what I tried to do. I changed the code to ACCEPT='application/json' and still never got the views to respond. I decided to name the view 'json' just to get going.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment