Implementing an example Todo-Backend REST API with Symfony 4 and api-platform

Todo-Backend lists many implementations of the same REST API with different backend-oriented Web development frameworks.

I’ve proposed my own version using Symfony 4 in PHP, and the api-platform project which helps implementing REST APIs.

I’ve documented the way I did it in the project’s documentation in details, for those curious about Symfony development of a very simple REST API (JSON based). See its README file (of course redacted with the mandatory org-mode ;).

You can find the rest of the code here : https://gitlab.com/olberger/todobackend-symfony4.

AFAICS api-platform offers a great set of features for Linked-Data/REST development with Symfony in general. However, some tweaks were necessary to conform the TodoBackend specs, mainly because TodoBackend is JSON only and doesn’t support JSON-LD…

Oh, and the hardest part was deploying on Heroku, making sure that the CORS headers would work as expected :-/

 

 

Publishing RDF views for tastypie/django resources

Here’s some documentation about a hack I’ve been working on to allow publication of RDF views for Tastypie resources (in Django applications).

While working on implementing support for RDF meta-data for descriptions of Debian packages for the Debian Package Tracking System rewrite, I’ve tried and idetify which libraries/frameworks would allow to create some RDF views for Django model objects with a minimal effort.

Ideally, this would save the hassle of writing code, and could just be a matter of mapping some Django model fields to proper ontology attributes.

I haven’t found an existing tool to do so, but it seemed to me that Tastypie could offer a nice starting point. Tastypie (I focused on v. 0.9.15 which is currently in Debian testing) offers some REST content-negociation support, and other niceties.

This post is an attempt at documenting an initial implementation for my problem. I’ve implemented it as some code in the example blog application described in the Tastypie documentation. Unfortunately, it’s not yet a patch that could be applied to Tastypie, to add this as a standard feature.

The code is available in my git clone of Tastypie, based on 0.9.15, and lies in the commit(s) between the example_myapp and rdfviews branches. It needs an up to date RDFLib to work (Debian’s is too old, btw).

It basically relies on the addition of a _rdf_mapping dict in the Django model objects, and an RdfModelResource as a base class for Tastypie ModelResources.

To provide an RDF view for a ModelResource, it also requires to declare a particular MetaClass, and adding a few bits to its Meta subclass.

The principle is that the dehydratation steps of the Tastypie system will replace fields values by their RDF objects counterparts, as either RDFLib Literals or URIRefs. Then the resuting Bundle will be converted to some RDFLib Graph. It is then just a matter of serialization of that Graph to turtle (I’ve not added another format, but it should be pretty straightforward).

There’s a bit of hackish drak magic in the code, in particular when introspecting the Tastypie / Django resource / model objects to be able to dynamically add some dehydrate_FOO methods to perform the conversion to Literals or URIRefs.

Custom dehydrateFoo methods can still be written to process the fields in particular ways.

I’ve added some LDP style paging along the way, so I hope it will be quite usable by LDP compatible tools.

Here’s the result :

First, listing all resources :

$ curl -H 'Accept: text/turtle' "http://localhost:8000/api/v1/entry/"
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

</api/v1/entry/#list> dcterms:hasPart </api/v1/entry/1/#post>,
</api/v1/entry/2/#post>,
</api/v1/entry/3/#post> .

Then, details of one particular post :

$ curl -L -H 'Accept: text/turtle' "http://localhost:8000/api/v1/entry/1"
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix sioc: <http://rdfs.org/sioc/ns#> .
@prefix xml: <http://www.w3.org/XML/1998/namespace> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

</api/v1/entry/1/#post> a sioc:Post ;
dcterms:created "2011-05-21T22:46:38+00:00"^^xsd:dateTime ;
dcterms:title "Another Post" ;
sioc:content "MESSAGE: This will prbbly be my lst post. /MESSAGE" ;
sioc:has_creator </api/v1/user/1/> ;
owl:sameAs </posts/another-post#post> .

I hope this is usable, and welcome any feedback.

Qu’est-ce que OSLC (Open Services for Lifecycle Collaboration) ?

Ce qui suit est une traduction en français que j’ai réalisée pour les sections d’introduction aux spécifications d’OSLC Core. Je pense qu’elles donnent quelques informations générales sur ce qu’est le standard OSLC, qui seront éventuellement utiles aux non-anglophones. Bien-sûr cette traduction ne se substitue pas à l’original, et est limitée aux paragraphes d’introduction, le détail des specs étant à lire en anglais dans le texte.

Introduction

L’initiative « Open Services for Lifecycle Collaboration » (OSLC) crée une famille de spécifications de services web pour des produits, services et autres outils qui soutiennent toutes les phases du cycle de vie des logiciels et produits. Continue reading “Qu’est-ce que OSLC (Open Services for Lifecycle Collaboration) ?”

Some news of our efforts around OSLC-CM and future plans

OSLC-CM V1 is a proposed standard for REST APIs of bugtrackers, and in our seek for more interoperability in the bugtracker space, we’ve been very interested in it.

OSLC-CM is quite young and only so far implemented in proprietary tools (although elaborated in an open way) on the server side, and as we believe in FLOSS, we’ve started trying to implement basics of server side plugins for a few bugtrackers.
In addition to a demo server that’s simulating the behaviour of a bugtracker, we have started implementing a Mantis plugin and FusionForge and Codendi trackers add-ons (all PHP and based on Zend framework, see this project on picoforge). All are very basic, but we hope they will be the basis for future OSLC-CM compatible servers in these tools.

At the same time we’ve been experimenting with the code already published in Mylyn to support OSLC-CM on the client side. Not everything is public yet in Mylyn, as the elements that have been developped for some connectors of Tasktop to the proprietary tools are being ported to the open source code of Mylyn.
We have thus been able to use the Junit tests classes of Mylyn and tweak them in a way to connect to an instance of the demo server for Mantis (including handling some Basic auth), and be able to retrieve the first bugs descriptions 🙂

Now that this works, we’ll try and add some Java code (maybe reusing Mylyn client libs) to doc4 (being developped as part of Helios) in order to start linking doc4 and Mantis so that this can be used in the Helios platform. This may involve mixing code of XWiki and Mylyn… hmmm… well, we’ll see.

Next steps may be also to try and implement a connector in Python that might be used in tools like bts-link.

Then whichever Python or Java client libraries we have, will allow us to use them inside FetchBugs4.me to connect and harvest bugs of OSLC-CM compliant bugtrackers eventually.

Lots of interesting developments ahead. Stay tuned.

First release (0.1) of a far from complete OSLC-CM V1 demo server

We’re working on implementing a demo/test server for the OSLC-CM V1 protocol, in order to help test client tools.

We’ve released (under a BSD license) a first 0.1 preliminary version that only supports GET queries, that’ll lead the way to an expected complete demo server of OSLC-CM V1 when the 1.0 version will be finished.

At the moment, it will only provide a minimal REST implementation of a PHP server using zend, and will produce JSON or XML/RDF views of fictionnal bugs contructed out of contents of a CSV file.

More details may be found at : https://picoforge.int-evry.fr/cgi-bin/twiki/view/Oslc/Web/, whereas the code is in the Download page there.