API Layer for reading and changing content based on TCA

Archive Discuss Topics
1

Discussion Topic

Today, users are consuming data in various multi-channel ways. Displaying Data in a website is no more the only way to communicate. Data must be accessible to external applications not only in read mode, but also in write mode.

Currently TYPO3 is not providing an « easy » access to the data. Of course, you can export the data in JSON or XML formats, but no API solution so far.

Impact

Based on TCA and BE/FE users permissions, I’d like to add a layer to TYPO3 that allows the devs to easily create an access to any data in TYPO3, through an API interface.

This extension will be optional (as many of the core extensions), but once installed, it automatically adds an API access to data, allowing external application (mobile, …) to make request to TYPO3. At the same time, those application will also be able to modify the data in TYPO3.

As this is based on TCA, the structure of the data returned or insert by the API is already available. Additional configuration on TCA may not be required at all ! (but I didn’t study all scenarios yet, of course).

In theory, TYPO3 will be able to control who is interacting with the data (which fields can be exposed, edited, …) and will also have a control of the format that is store in DB (RTE fields, date, …).

This project must be « technology independent ». I mean, the choice of using Rest, Soap or Graphql is not the topic of this discussion (even if I have an opinion about that :wink: ). This choice can be done later… Most important, if in 2 years, an new fancy API trend technology is rising, our API layer should be able to welcome that new technology easily.

Pro

  • Central API can be used to enable all kinds of services around it
  • This API could also be used to pull in and expose data for rendering in Fluid templates

Con

  • Nothing yet

Remarks and notes

Question is whether there are objections from anyone against creating such API based on TCA information

Organizational

Topic Initiator: Roberto Presedo
Topic Mentor: Helmut Hummel

2

I like the idea a lot, and I have no objections.

3

Sounds really GREAT! I can also not see any drawbacks/cons right now.

4

Great idea and definitely something, that will be very useful.

5

I just realized, that this is totally in line with the already existing persistence initiative: https://typo3.org/community/teams/typo3-development/initiatives/persistence/

Roberto will gladly join it

6

Definitely sounds like something useful.

I think an important con that should have been mentioned would be potential security issues. This would open up a brand new attack surface, which would potentially be accessible by non-logged in users. While I am sure we’ll do our best, we probably cannot guarantee they won’t be a bug, or something, that would lead to security issues.

7

Would be interesting to get in touch with them in that case. I just pointed this discussion on the associated slack channel (#cig-persistence). I really believe it is an import feature (if not killing feature) and we could split work. There should be some work doable in parallel as of phase #1 (see the initiative page). Would be interested to know the status of the discussion / vision.

Also the system must be built to be agnostic enough of the API technology. For instance, nowadays we tend to prefer GraphQL which would enable us to retrieve more information at once. I guess / hope we don’t have to reinvent the wheel here (the API layer) and they would be some package to connect.

8

I really like the idea.

9

Totally awesome, yes!!

10

have a look at the Contexts API, which is a start to centralize all the properties currently distributed in so many global objects and variables (EXEC_TIME, TSFE etc).

https://review.typo3.org/#/c/57104/

I think a generic API, at least for reading, can be easily achieved then based on TCA and Contexts. Writing could follow then.

As for authentication, I think some ground work needs to be done in AbstractUserAuthentication to be more flexible.

11

yes please do it - I welcome your initiative

12

Would it make sense to integrate symfony/apiplat (or at least some parts in order to prevent creating something potentially broken for years with bad acceptance) and add a TCA layer?

I mean, some parts of the core are already plain symfony and apiplat is AFAIK feature complete, so the bulk work to do here would be to register a new model parser (or something like this) in order to expose all we have in multiple formats and build it in a way that the extension developer can set a flag in TCA in order to expose the table/model to the outside world.

In any case, an integrated, easy to use API is a good step forward, no matter how we decide to proceed.

13

Before we could even think about apiplatform, we need to think about our domain models, and that’s just incompatible with symfony persistence. Doctrine ORM and Extbase ORM have different feature-sets (yes, Extbase does have features that Doctrine ORM does not have) and it’s hard to keep them compatible.

I think apiplat is really nice, but there needs to be a lot of work done to get in this direction, including migration of existing extbase extensions to become Doctrine ORM compatible.

14

In favor. Sounds promising

15

Sounds like something that the rest of the CMS should also use internally. Using it with whatever format to read and write data is then “only” a matter of transforming data structures.

16

This topic was automatically closed after 14 days. New replies are no longer allowed.