-
Notifications
You must be signed in to change notification settings - Fork 173
There are no plans to integrate views. If your use case is simple enough, probably you can do most of what you'd expect from that with views data sources.
The biggest differences are: using the D8 plugins that are backported using the Plug module, and a new architecture with a clear separation. Hopefully the new architecture will empower small contrib modules.
The Plug module is a dependency of 2.x. We are swapping CTools for Plug as a dependency.
In addition 1.x only needs PHP 5.3.10 where 2.x requires at least 5.4.
(as at 16 September 2015) That's hard to say, we've been making great progress lately but I don't think that it's as stable as 1.x if you use the full CRUD.
(as at 16 September 2015) If your data model is very straight forward, with few relationships you can use 1.x. If you have many relationships and are not afraid of having to debug from time to time, I would recommend 2.x.
Will there be an upgrade path between 1.x and 2.x? How do you see users handling a switch from 1.x to 2.x?
It's not automatic, since this are not records in the database but plugin files. Changing from one to another is going to be very straight forward 90% of time.
You will need to manually transform your resources. See how the examples from 1.x got transformed; they should be the exact same example in 2.x.
Not many. D8 REST is more similar to RestWS than to RESTful.
There will be many more features than what D8 REST currently has. D8 REST is currently a great proof of concept of the WSCII initiative, and will power most of the simplest cases of: «I want to expose my articles and I don't care how».
Hopefully yes. The resources in RESTful D7 2.x should be compatible with RESTful D8.
There is! There is a sample repo, and some demo videos.
https://events.drupal.org/barcelona2015/sessions/expose-drupal-restful
Here (GitHub) is a good place. Both @amitaibu and I (@e0ipso) are very responsive here. I'd say follow @theodorosploumis's lead, find a piece you are interested in and dive into it. If you have questions we'll be happy to address them. Or follow yours and fix the bugs you encounter along the way :-)
I see you can use view modes (personally have not used). Would you recommend using them...keeping the output logic in the CMS/Database, or would recommend the output logic in your endpoint code
I think that view modes are a good way to simplify your public fields, and maybe it's the first part that deserves a UI. But if you need full CRUD, or you know how to do it with the publicFields definition, then stay with that.