The path for JSON API to core

TODO (e.g. content_moderation_rest_resource_alter() opts out entity types from APIs; until there's a generic API for this, mirror those)

The ResourceTypeRepository service will allow to do that. One can decorate the service and filter the resources out for that purpose. If that DX is too convoluted we could add a hook_alter (or similar), but I think it makes sense to keep that pattern we are already using in JSON API Extras.

TODO (re-analyze code base to make as much as possible @internal)

This is a check, I don't expect much work to come out of this. Good caution nevertheless!

TODO (also test collections, related, include, sparse fieldsets etc -> don't test every include, just one, etc)

We'll need to come up with a reasonably complex use case for the test. We need to make sure to add that to the issue summary when one is created.

One can decorate the service and filter the resources out for that purpose. If that DX is too convoluted we could add a hook_alter (or similar)

Given that this is a temporary solution, I think the alter option is the better DX. We don't want to make developers spend a ton of time on something which they can just delete later. Let's make sure the hook is immediately marked as deprecated.

But it does mean this will need to become a non-internal API. So we should be very very careful with that, because we'll have to support it forever.

That's a good point. I think we have consensus on hook_alter + deprecation.

I don't think we need #2923779: Normalizers violate NormalizerInterface to be added here. Any strong feelings about it?

@gabesullice and @Wim Leers pointed me at this issue. Exciting! A few initial questions and comments:

1. A) the same data is exposed by core REST + JSON API + GraphQL + RELAXed Web Services
   B) the pieces of data that should be normalized in the same way across all of the above, are normalized in the same way

   This sounds like the most important piece to me for core inclusion.

2. BC breaks are detected before they are committed.

   Does this mean BC for the module API between the contrib module and core? Test coverage preventing BC breaks for the exposed API (i.e. the JSON API API itself, not the PHP API)? Something else?

3. Security vulnerabilities are proven to be absent.

   This is impossible to prove. :) What I'd say instead is:

   • No known security issues with the JSON API module in the public or private trackers.
   • Verifying that JSON API is also hardened against the access bypass and unserialization injection issues that were fixed in core REST last year.
     (If issues are identified they should be reported privately as security issues, not discussed here, since the contrib module has stable releases.)

    

4. It looks like there's some question as to whether #2923779: Normalizers violate NormalizerInterface is a required part of the roadmap or not. This would probably fall under the architectural review for the module and I expect we'd want to answer the question (whether it's "yeah we need to fix this" or "wontfix" or something in between) before the module were marked stable for core, but it doesn't need to block adding the module as an alpha module.

   We can ask the framework managers about the issue when the time comes, but I think that can come after some of the other priorities and I think it's okay if it's an open question when the module is initially added to core.

From #19

the JSON API contrib module needs to be added to Drupal core with at least beta-level stability

I agree with this statement. +1.

From #18

Verifying that JSON API is also hardened against the access bypass and unserialization injection issues that were fixed in core REST last year.
(If issues are identified they should be reported privately as security issues, not discussed here, since the contrib module has stable releases.)

That's a great suggestion. I'll make sure that's added to the current priorities.

It looks like there's some question as to whether #2923779: Normalizers violate NormalizerInterface is a required part of the roadmap or not.

Yeah, I'm feeling that we'll have to do a videochat meeting for that one. I think that the suggestion is well intentioned but I feel there are several non-obvious problems that may make this impossible (or too big of a task to be worth it). And moving forward with it will definitely break BC. That's why I'm leaning towards wontfix or do some more preliminary investigation when all priorities are knocked off.

#2935947: Comply with code standards was merged.

@xjm we met and debated about #2923779: Normalizers violate NormalizerInterface and we decided on the course of action. This should address #18.4.

PS: Meeting notes available.

@xjm we also have #2936673: Add explicit JSON API test coverage for security issues already uncovered in REST core to make sure we explicitly cover the security vulnerabilities uncovered in REST core.

Is there anything lingering from your questions above that you'll like to see addressed?

We got a ton of commits in this past week! 🎉

#2921257: On Drupal 8.5, JSON API should respect Typed Data's new ::isInternal(), and JSON API Extras should use ::setInternal() is now fixed!

#2940342: Cacheability metadata on an entity fields' properties is lost is also resolved.

Added #2937797: Entity UUID Converter performance to the list.

#2945093: Comprehensive JSON API integration test coverage phase 3: test JSON API-specific use cases: related/relationship routes, includes and sparse field sets landed!

I've added two new issues:
#2953318: Comprehensive JSON API integration test coverage phase 4: collections, filtering and sorting
#2953321: Comprehensive JSON API integration test coverage phase 5: nested includes and sparse field sets

That will leave POST/PATCH/DELETE of individual resources and relationships

Can you explain that a bit? :)

There is a requirement for performance for inclusion of a contrib into core. This feels like a necessary fix in that regard. Regardless, this was merged and fixed already.

Now #2950744: Move relevant test coverage from jsonapi_extras to jsonapi is fixed. We can move all of our attention to the two remaining issues.

JSON API is hardened to the same extent as core's REST API.

But why JSONAPI duplicates rest functionality? Why JSONAPI can not work through REST plugins system?