It should be possible to list the content type of items in a container/collection about plone.restapi

[lukasgraf]

I recently did this in our own project integration of plone.restapi.

I would propose to include @type in the default summary (and maybe drop description while we're at it). @tisto any thoughts regarding this?

---

@pigeonflight for now, this can be done by registering your own ISerializeToJsonSummary adapter for your project's browser layer:

from my.project import IMyProjectLayer
from plone.restapi.interfaces import ISerializeToJsonSummary
from plone.restapi.serializer.summary import DefaultJSONSummarySerializer
from zope.component import adapter
from zope.interface import implementer
from zope.interface import Interface


@implementer(ISerializeToJsonSummary)
@adapter(Interface, IMyProjectLayer)
class MyJSONSummarySerializer(DefaultJSONSummarySerializer):
    """Customize summary representations to include the object's portal_type.
    """

    def __init__(self, context, request):
        self.context = context
        self.request = request

    def __call__(self):
        # Get the default summary first, then modify it as needed
        summary = super(MyJSONSummarySerializer, self).__call__()

        # Include portal_type
        summary['@type'] = self.context.portal_type

        return summary

    <adapter factory=".summary.MyJSONSummarySerializer" />

Note that this will override the DefaultJSONSummarySerializer and therefore affect summary representations for items other than the site root in all places (not just collections, but also relation lists, folder contents, parent pointers (and eventually search results)).

Also note that plone.restapi is still in pre-alpha state: This behavior might still change in the future.

[pigeonflight]

@lukasgraf thanks for the pointer, will look into that.

Definitely keep description. plone.restapi advertises itself as an "out of the box" restful api for Plone. In that context the description is important.

Having the type will allow me to filter the json results based on content type.

BTW.. I'm on a project now where we're using Plone as an API.

update:
@lukasgraf I just tested the workaround. Works very well. I needed to swap out the "IMyProjectLayer" of course for my own, apart from that, it works as advertised! Thanks again.

[tisto]

@lukasgraf +1 for adding a type to listing (and keep the description). I wasn't 100% sure if we should use "@type" or just "type" since "@type" has a very specifig meaning in JSON-LD/Hydra. Though, I think "@type" is the correct key to use. See:

https://www.w3.org/TR/json-ld/#typed-values
https://www.hydra-cg.com/spec/latest/core/#collections
http://stackoverflow.com/a/25306010/644831 (first answer by the main author of hydra)

[lukasgraf]

I also believe @type is correct - the way I understand it, it should be a term in one of the document's vocabularies. Eventually, that term should be derefenceable (be an URI that can actually be fetched), but it may very well be a relative URI, as described in the StackOverflow example above.

The way I understand it, we would eventually be building our own dynamic JSON-LD contexts, vocabularies and types, based on information from FTIs, (probably annotated) schema interfaces, and field types. Related: #11