Core Merging Plan for the API #571
The key to getting the API into core is breaking the merge into steps. I've been talking these through with the rest of the team at WCSF, and we're going to break this up into a few basic steps.
Each of these steps has challenges, but the idea is to try and handle these step-by-step to chip away at the larger task.
At the end of each step, we'll stop and make sure we've completed everything we wanted to, ensure we have nothing else to do, then shepherd it into core. The next step doesn't start until the previous is fully complete.
The actual process of finalising each step will be to separate the relevant code into a separate repository, then formatting it as a core patch. These can then be reviewed separately, and merged into WP core at the behest of the core team. (The actual timing for this depends on the release cycles and such, but
Step 0: Reinvigorate the two-dot-oh branch
We've decided internally that the resource approach taken on
There's plenty that we've done on the
Step 1: Pushing ahead with infrastructure
The first part up for merge is the infrastructure. This is the bare basics to run any sort of API, and will consist primarily of our
Server Code (Routing, Serialisation, etc)
Step 2: Making our core objects available
Once the infrastructure is in core, let's work step-by-step and evaulate our core objects. These are the Core Objects: Posts, Comments, Terms and Users. This also includes meta for each (except terms).
This does not include options or similar (plugins, themes, customiser endpoints,
(PCTU = Posts, Comments, Terms and Users)
Step 3: Periphery
Now that core has the vast majority of the API in place, it's time to worry about all those extras we missed out on the way.
Once the process is complete and the API is merged, we can move on to new features outside our main focus. These can also happen in parallel if we have sufficient resources (i.e. people) to handle these as well.
The text was updated successfully, but these errors were encountered:
This is conflating two issues I think. Sending multiple requests as a matter of convenience to reduce HTTP requests shouldn't be conflated with "How should we support creating multiple Resources in one request" as that brings the complexity that Daniel highlights above. It seems we need a ticket to just support multiple parallel independent requests which would return each response enveloped in someway.