One of the idea's our developers came with is the ability to have some sort of versioning. So the usecase would be:

* API is exposed and used (perhaps jsonapi/v1/resource)
* Change is made to the API (removed a field) and this version is published at v2 (jsonapi/v2/resource).

This would mean you could change the API for your clients and keep backwards compatibility.

I feel this is quite usefull and could help in situations where a JSON:API is exposed to multiple clients.

Issue fork jsonapi_extras-3218679

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

bbrala created an issue. See original summary.

bbrala credited casey.

bbrala’s picture

bbrala
Location Netherlands
commented

Credit casey for the idea. :)

e0ipso’s picture

e0ipso
Primary language Catalan
Location Can Picafort
commented

I have been on this path before (see the Restful module) and I was not able to reach a satisfactory state. This is because the automatic API generation is a great feature, maybe the best one, but it ties your API to your content model irrevocably. This means that you cannot have 2 content models going at the same time, v1 where `field_foo` is a string and v2 where `field_foo` is a multivalue integer. Such thing happens because we only have one database instance per Drupal install, with a specific table layout.

You could, of course, limit the versioning to things that happen within JSON:API Extras. I have avoided that as well in the past after talking to several people about it. I reached the conclusion that they found too confusing when it works and when it does not, which led them to tell me they wouldn't use it because of it.

Sorry for the discouragement, my goal is not to bring down but to save time/effort. It goes without saying that where I didn't succeed you very well can. Let me know if you want to bounce ideas.

bbrala’s picture

bbrala
Location Netherlands
commented

Thanks for the writeup, no need to apologise, always good to have more angles available on a subject.

I do understand the rabbit hole we might dive in should we do this. The fact that you cannot revision content configuration in core makes things rather opague which might be a problem.

When (or if) i have the time i will writeup how this could work, if it even can work and see if it is realistic. I'll get in touch should i get to that point, always good to talk things through. :)

lhuria94’s picture

lhuria94 commented

Are there any further discussed happened related to this topic? We have reached a point where we are also looking at versioning our APIs in Drupal but it seems its a rather unrealistic scenario.

vaza18’s picture

vaza18 commented

We are also looking at versioning our APIs in Drupal at least the way when:
- different set of resources can be enabled/disabled for different versions;
- different set of fields can be enabled/disabled per resource for different versions;
- different field enhancers can be applied for different versions.

vasyapledov made their first commit to this issue’s fork.

vasyapledov changed the visibility of the branch 3218679-ability-to-expose to hidden.

vasyapledov changed the visibility of the branch 3218679-ability-to-expose to active.

vasyapledov opened merge request !58

vasyapledov’s picture

vasyapledov commented
Assigned: Unassigned » vasyapledov

MulitAPI

This is the very draft variant of MultiAPI.

MulitAPI Functionality

  • Unilimited numbers of JSON:API variants
  • Independent JSON:API variants
  • JSON:API variants can be enabled/disabled independently of each other
  • JSON:API variants have independent path prefixes
  • Special Information for every API variant - release date, special name, description
  • Independent permissions for every API variant

Description

README MultiAPI.md

Installation

ATTENTION! Before installation need to install core patch
https://www.drupal.org/project/drupal/issues/3460831 - implemented inside composer.json

Planned extensions

  • Add information for every API variant - release date, special name, description

    •  - done
  • Add independent permissions for every API variant

    •  - done
vasyapledov’s picture

vasyapledov commented
Status: Active » Needs review

At last - to review. :)

fjgarlin’s picture

fjgarlin commented

@e0ipso @bbrala - is this MR something that you could review and give feedback about? The rest of us can look at it but won't have such deep understanding of what's in core and in jsonapi_extras.