Closed (fixed)
Project:
Drupal core ideas
Component:
Active Initiative
Priority:
Major
Category:
Plan
Assigned:
Unassigned
Reporter:
Created:
15 Feb 2017 at 13:56 UTC
Updated:
13 Sep 2017 at 08:55 UTC
Jump to comment: Most recent
This is happening as part of #2757967: API-first initiative. It's the successor to #2794263: REST: top priorities for Drupal 8.3.x, which was the successor to #2721489: REST: top priorities for Drupal 8.2.x.
Theme: Make Drupal 8’s REST best-in-class
.
PATCH + POST test coverage/reliability: #2882717: EntityResourceTestBase: assert that PATCHed and POSTed entities contain the intended values
Comments
Comment #2
wim leersComment #3
wim leersForgot to omit one that was fixed in 8.3 :)
Comment #4
wim leers#2649646: Normalize path fields as part of the entity: allow REST clients to know the path alias was closed as a duplicate of #2846554: Make the PathItem field type actually computed and auto-load stored aliases, updating IS.
Comment #5
wim leers#2826407: PATCH + POST allowed format validation happens in RequestHandler::handle(), rather than in the routing system was actually discovered by #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method, and there's a
@todofor it inEntityResourceTestBase, but I forgot to add it to #2794263: REST: top priorities for Drupal 8.3.x. So it fell off the radar. That won't happen again now.Comment #6
wim leersAdding #2737751: Refactor REST routing to address its brittleness.
Renamed the section to — sometimes mere untangling of broken architecture and fixing it can also be important for those 4 things. #2737751 is an example of that. It's been haunting us for years. Time to fix it.
Comment #7
wim leersAdded #2853460: Simplify RequestHandler: make it no longer ContainerAware, split up ::handle() and #2775479: Try to remove the "map HEAD to GET" logic in \Drupal\rest\RequestHandler::handle().
Comment #8
wim leersAdded #2854543: NegotiationMiddleware calls $request->setRequestFormat('html') when there is no _format request parameter, but shouldn't and #2854560: \Drupal\Core\Routing\RequestFormatRouteFilter::filter() is too HTML-centric as JSON API blockers.
Comment #9
wim leers#2775479: Try to remove the "map HEAD to GET" logic in \Drupal\rest\RequestHandler::handle() landed!
Comment #10
wim leers#2854560: \Drupal\Core\Routing\RequestFormatRouteFilter::filter() is too HTML-centric landed!
Comment #11
wim leersAdded #2854830: Move rest/serialization module's "link manager" services to HAL module, which also just landed!
Comment #12
wim leers#2825347: 'Accept' header still is used for determining response format of error responses, ?_format= has no effect AND serialization module's exception subscriber does not support status code 500 error responses landed, yay!
Comment #13
gábor hojtsy#2843147: Add JSON:API to core as a stable module is not listed as a priority. Any reasons for that?
Comment #14
wim leersAdded #2853300: Standardize fatal error/exception handling: backtrace for all formats, not just HTML.
Comment #15
wim leers#13: because JSON API != REST. They're orthogonal. They do both rely on the
serializationmodule though. So many of the fixes that we are landing for the REST module also help the JSON API module.You should consider this issue on the same level as #2836165: New experimental module: JSON API: both this and that issue are plan issues in the "Drupal core ideas" queue. And #2843147: Add JSON:API to core as a stable module is the child issue of #2836165 against Drupal core, so that that we can have a patch that is tested against core.
Comment #16
wim leersI totally forgot to add #2824717: Add a format constraint to DateTimeItem to provide REST error message to #2794263: REST: top priorities for Drupal 8.3.x! Adding it here now.
Comment #17
wim leersPer #2100637-156: REST views: add special handling for collections and later comments, we decided to not pursue this in core. We collectively agreed that it makes more sense to defer this to JSON API for now. Since #2099281: [PP-1] REST views: pagination link relations depends on #2100637, that issue is also impacted.
Removed those two.
Comment #18
wim leers#2648268 was deprioritized at #2648268-35: REST views: row-level caching doesn't exist, unlike for other types of views two weeks ago. Also removing it from this list.
Comment #19
wim leers#2751325: All serialized values are strings, should be integers/booleans when appropriate landed! Inexplicably, this was not listed here. This has taken months to get fixed. It definitely has earned a place here.
Comment #20
wim leersAdded #2856110: [PP-1] Expose entity validation errors in a machine readable REST API: .
Comment #21
wim leersAdded #2847708: RPC endpoint to reset user password.
Comment #22
wim leers#2827084: EntityNormalizer::denormalize should not throw UnexpectedValueException, but \Symfony\Component\HttpKernel\Exception\UnprocessableEntityHttpException, so we get a 422 response instead of 400 is listed here, but it already landed at #2794263-63: REST: top priorities for Drupal 8.3.x. Removing it.
Comment #23
wim leers#2844046: REST Resource config entities do not respect the status (enabled/disabled) landed.
Comment #24
wim leers#2825487: Fix normalization of File entities: file entities should expose the file URL as a computed property on the 'uri' base field is already listed as a serialization gap, but it's also a JSON API blocker. #2353611: Make it possible to link to an entity by UUID is another JSON API blocker.
See #2842148-11: The path for JSON API to "super stability".
Comment #25
wim leers#2817745: Add test coverage to prove that REST resource's "auth" configuration is also not allowing global authentication providers like "cookie" when not listed landed!
Comment #26
dawehnerI just added #2850034: CORS allow-origin '*' not possible because of cached headers
Comment #27
wim leers#2826407: PATCH + POST allowed format validation happens in RequestHandler::handle(), rather than in the routing system just landed!
Comment #28
wim leersFinally, another serialization gap closed! #2827164: Entity reference field normalization has target_type and target_uuid, but not used in denormalization is in :)
Comment #29
wim leers#2850034: CORS allow-origin '*' not possible because of cached headers landed!
Comment #30
wim leersAnd #2853300: Standardize fatal error/exception handling: backtrace for all formats, not just HTML also landed!
Comment #31
skyredwangMaybe #2870609: [PP-1] Core Date field is serialized as String instead of timestamp/long worth some attention?
Comment #32
wim leersThat's in JSON API, not in Drupal core's REST. We already have issues for the normalization of TimestampItem and DateItem in Drupal core.
Comment #33
wim leers#2824717: Add a format constraint to DateTimeItem to provide REST error message landed, which solves one half of the serialization gap problem.
Comment #34
wim leersAdded #2827797: ResourceResponse(Subscriber) + Dynamic Page Cache: making authenticated ResourceResponses significantly faster + #2765959: Make 4xx REST responses cacheable by (Dynamic) Page Cache + comprehensive cacheability test coverage. They're super important for maintainability/reliability, and long-term velocity.
Comment #35
wim leers#2768651: Let TimestampItem (de)normalize to/from RFC3339 timestamps, not UNIX timestamps, for better DX landed! Finally :)
Comment #36
wim leersAdded #2882717: EntityResourceTestBase: assert that PATCHed and POSTed entities contain the intended values to .
Comment #37
wim leers#2846554: Make the PathItem field type actually computed and auto-load stored aliases landed! This is the third serialization gap we close.
Comment #38
wim leers#2847708: RPC endpoint to reset user password landed!
Comment #39
wim leers#2882717: EntityResourceTestBase: assert that PATCHed and POSTed entities contain the intended values landed!
Comment #40
wim leers#2824851: EntityResource::patch() makes an incorrect assumption about entity keys, hence results in incorrect behavior just landed and I notice now that it wasn't listed here. Added to the section.
Comment #41
wim leersThanks everybody for helping out here!
We didn't make as much progress as I'd hoped in some areas (serialization gaps), but we made far more progress in other areas (test coverage). But obviously we fixed tons of issues, many of them requiring fixes in other subsystems. We achieved roughly half of the top priorities!
Note that of the 69 issues that are tagged with , of which 10 are for the API-First Initiative — or 14% of all release notes issues!
Now it's time to move on to 8.5.x. I've opened #2905563: REST: top priorities for Drupal 8.5.x for that, which is the continuation of this issue.
Thanks, and see you around!
(Sister posts at #2794263-64: REST: top priorities for Drupal 8.3.x and #2721489-48: REST: top priorities for Drupal 8.2.x.)
Let's do a restrospective. We landed:
Many of them were very difficult to land, requiring lots of consensus building, or requiring blockers to be solved that aren't listed here, often in other subsystems. Many of the ones that did not land are already well on their way, making it very likely that they will land in 8.5.