The end goal is to have the stability of the dynamic_page_cache and big_pipe modules, which thanks to their rigorous test coverage have seen barely any bug reports over the course of more than a year. To achieve that, we may need a level of functional test coverage similar to the REST module (as added in #2737719: EntityResource: Provide comprehensive test coverage: for every entity type, every format, every method).
Roughly in order of sensible execution, but many things can be done in parallel.
Drupal\jsonapi\Resource\EntityCollectionDrupal\jsonapi\Resource\JsonApiDocumentTopLevelDrupal\jsonapi\RequestCacheabilityDependency, issue: #2846659: Remove \Drupal\jsonapi\RequestCacheabilityDependency, use \Drupal\jsonapi\JsonApiSpec::getReservedQueryParameters() insteadsrc/Access, issue: #2829328: Clean up Drupal\jsonapi\Access\CustomParameterNames and make it follow the spec more closelysrc/Context, issues: #2842145: Add comprehensive unit test coverage for \Drupal\jsonapi\Context\FieldResolver + #2930228: Refactor CurrentContext awaysrc/Error, issue: #2829977: SerializableHttpException and Drupal\jsonapi\Error\* are not necessarysrc/FieldResolversrc/Normalizer, issue: #2860350: Document why JSON API only supports @DataType-level normalizers (will likely need more issues)src/Query, issue: src/Routing/Paramsrc/Field, blocked on #2825487: Fix normalization of File entities: file entities should expose the file URL as a computed property on the 'uri' base field, issue: #2926463: [>=8.5] Remove JSON API's "file URL" field work-around now that Drupal core 8.5 fixed itsrc/LinkManager, blocked on #2854830: Move rest/serialization module's "link manager" services to HAL module, issue: #2829746: Clean up \Drupal\jsonapi\LinkManager\LinkManager(Interface)src/ParamConverter, blocked on #2353611: Make it possible to link to an entity by UUIDsrc/ResourceResponseInterface, fixed in #2857658: Get rid of ResourceResponseInterface
Comments
Comment #2
wim leers#2353611: Make it possible to link to an entity by UUID would allow JSON API to remove
\Drupal\jsonapi\ParamConverter\EntityUuidConverter.Comment #3
wim leers#2846659: Remove \Drupal\jsonapi\RequestCacheabilityDependency, use \Drupal\jsonapi\JsonApiSpec::getReservedQueryParameters() instead landed, which addressed one of the bullets in the IS.
Comment #4
wim leersComment #5
wim leers#2840677: Validate responses against the JSON API specification, #2829328: Clean up Drupal\jsonapi\Access\CustomParameterNames and make it follow the spec more closely and #2829746: Clean up \Drupal\jsonapi\LinkManager\LinkManager(Interface) all landed quite some time ago, each of them result in a bullet being addressed!
Comment #6
dawehnerI'm really wondering how useful is to have this interface in the first place
a) Why would anyone want to have a different implementation of that
b) This class seems to be mostly handled internally. Maybe we don't need an interface in the first place?
Comment #7
wim leers#6++, exactly :)
Comment #8
e0ipso+1 to #6.
Comment #9
dawehnerComment #10
wim leers#2857658: Get rid of ResourceResponseInterface landed :)
Comment #11
wim leersRemoving
src/Fieldis blocked on #2825487: Fix normalization of File entities: file entities should expose the file URL as a computed property on the 'uri' base field. And removingsrc/ParamConverteris blocked on #2353611: Make it possible to link to an entity by UUID.That means at least two things in this Plan issue are blocked on core issues.
Comment #12
wim leers#2829327: Review JSON API module for core-readiness is done! That means this is now the most important remaining plan issue.
Comment #13
wim leersIt seems that I was right in wanting to review more of the architecture of the JSON API module, because if I'd gotten to
I'd definitely have found #2860350: Document why JSON API only supports @DataType-level normalizers. This is probably the most critical bug since we started tagging stable releases.
Comment #14
wim leers#2874601: refactor(QueryBuilder): Improve testability/maintainability is tackling for the
src/Querysubnamespace! 🎉Comment #15
wim leers#2874601: refactor(QueryBuilder): Improve testability/maintainability landed, which makes the situation/status of
src/Querya lot better! 🎉Comment #16
wim leersAdded #2921257: On Drupal 8.5, JSON API should respect Typed Data's new ::isInternal(), and JSON API Extras should use ::setInternal(), because it's so important for the API-First ecosystem of modules (REST + JSON API + GraphQL).
Comment #17
e0ipsoAgreed with #16.
Comment #18
wim leersCreated #2926463: [>=8.5] Remove JSON API's "file URL" field work-around now that Drupal core 8.5 fixed it to solve
src/Field.Comment #19
wim leersAdded #2917260: Validate against specific JSON Schemas if Schemata is present.
Comment #20
wim leersAdded #2860350: Document why JSON API only supports @DataType-level normalizers + #2929932: Work around core's ill-designed @FieldType-level TimestampItemNormalizer normalization until #2926508 lands + #2929935: Remove JSON API's ScalarNormalizer: it's no longer necessary thanks to #2751325's PrimitiveDataNormalizer.
Comment #21
wim leersWe've had in the issue summary since the creation of this issue.
As described in https://wimleers.com/blog/api-first-drupal-really, this is finally complete for core REST as of 1.5 week ago. So now we can do the same for JSON API. Created #2930028: Comprehensive JSON API integration test coverage phase 1: for every entity type, individual resources only.
Comment #22
wim leersAdded #2930228: Refactor CurrentContext away.
Comment #23
wim leersAdded #2930231: JSON API 403 errors don't tell the user *why* access is not granted: requires deep Drupal understanding to figure out.
Comment #24
wim leersAdded #2887313: JSON API indicates it supports POST/PATCH/DELETE of config entity types, but that's impossible.
Comment #25
wim leersAdded JSON API spec compliance issues: #2888132: JSON API spec compliance: Throw error if relationships are not stored under data + #2888889: JSON API spec compliance: Throw error if the "type" attribute is missing in write operations
Comment #26
wim leersAdded #2853066: Spec Compliance: Inaccessible collection/related resources surface errors: should be 200 with hypermedia + metadata.
Comment #27
skyredwangAdded a major bug #2920194: Inclusion of nested relationships fails for bundle-specific fields. But, I am not sure where would you put it in the summary.
Comment #28
e0ipsoI am confused by the tendency in this issue. It seems that every open bug is added here. I'm unsure how that highlights stability.
Comment #29
wim leers#28: I've not added a single minor bug. Only issues that are either important for BC/DX, or for architecture.
I believe all these issues are really important for the JSON API module to become really rock-solid and easy to maintain in core.
Comment #30
wim leers@e0ipso, you're right, the scope of this issue is now far beyond core-readiness. It's about getting the entire module's codebase to a super-maintainable point.
So, I opened a new issue specifically for core-readiness: #2931785: The path for JSON API to core.
This issue is therefore a superset of #2931785, and deserves to be postponed, because the highest priority issues can be found in #2931785: The path for JSON API to core.
Comment #31
gabesulliceComment #32
wim leersActually, only one issue in the IS has not yet been completed: #2853066: Spec Compliance: Inaccessible collection/related resources surface errors: should be 200 with hypermedia + metadata. That's now one of a handful remaining (strict) spec compliance issues. This issue has served its purpose — marking it !