Hey @danielbachhuber,

This looks pretty clear and defined I'd say, and if I understand correctly is just a "normal" class abstraction to build a concept of "resources" (something you can GET, UPDATE, and DELETE) in a standardised manor. I'm sold on the need for that, and also now this doesn't tie us into anything, you would presumably just register the endpoint in some manor like #551 so there is no "magic" there. However, I'm not sure how this differs really to what already exists with WP_JSON_Posts for example. You can extend that class and override methods where it makes sense and tie your class into a registered endpoint (or perhaps it's done through the parent class construct to be registered automatically). What is this offering over WP_JSON_Posts and associated posts, if we just want a "base" for all those classes, why not just add that in and abstract out some methods rather than writing a new here.

defined I'd say, and if I understand correctly is just a "normal" class abstraction to build a concept of "resources" (something you can GET, UPDATE, and DELETE) in a standardised manor.

Yep. The remaining pieces to support are:

• Checking context permissions
• Registering relationships with other Resource types

What is this offering over WP_JSON_Posts and associated posts, if we just want a "base" for all those classes

Clean slate for discussion so we're talking conceptually and not fighting legacy ideas.

why not just add that in and abstract out some methods rather than writing a new here.

If/when this PR is merged, the existing classes can be renamed, methods tweaked slightly, and extend this new abstract class. Taxonomies needs to be retooled anyway because it needs to be broken into a Resource and an informational endpoint.

I'm interested in @rmccue's opinion particularly too, because he didn't like the previous Resource implementation (which had some differences).

💣

Ooops, I meant 🚢