# EGroupware CalDAV/CardDAV server and REST API CalDAV/CardDAV is build on HTTP and WebDAV, implementing the following additional RFCs containing documentation of the protocol: * [rfc4791: CalDAV: Calendaring Extensions to WebDAV](https://datatracker.ietf.org/doc/html/rfc4791) * [rfc6638: Scheduling Extensions to CalDAV](https://datatracker.ietf.org/doc/html/rfc6638) * [rfc6352: CardDAV: vCard Extensions to WebDAV](https://datatracker.ietf.org/doc/html/rfc6352) * [rfc6578: Collection Synchronization for WebDAV](https://datatracker.ietf.org/doc/html/rfc6578) * many additional extensions from former Apple Calendaring Server used by Apple clients and others ## Path / URL layout for CalDAV/CardDAV and REST is identical One can use the following URLs relative (!) to https://example.org/egroupware/groupdav.php - ```/``` base of Cal|Card|GroupDAV tree, only certain clients (KDE, Apple) can autodetect folders from here - ```/principals/``` principal-collection-set for WebDAV ACL - ```/principals/users//``` - ```/principals/groups//``` - ```//``` users home-set with - ```//addressbook/``` addressbook of user or group given the user has rights to view it - ```//addressbook-/``` shared addressbooks from other user or group - ```//addressbook-accounts/``` all accounts current user has rights to see - ```//calendar/``` calendar of user given the user has rights to view it - ```//calendar/?download``` download whole calendar as .ics file (GET request!) - ```//calendar-/``` shared calendar from other user or group (only current !) - ```//inbox/``` scheduling inbox of user - ```//outbox/``` scheduling outbox of user - ```//infolog/``` InfoLog's of user given the user has rights to view it - ```/addressbook/``` all addressbooks current user has rights to, announced as directory-gateway now - ```/addressbook-accounts/``` all accounts current user has rights to see - ```/calendar/``` calendar of current user - ```/infolog/``` infologs of current user - ```/(resources|locations)//calendar``` calendar of a resource/location, if user has rights to view - ```//(resource|location)-``` shared calendar from a resource/location - ```/mail/``` REST API only Shared addressbooks or calendars are only shown in the users home-set, if he subscribed to it via his CalDAV preferences! Calling one of the above collections with a GET request / regular browser generates an automatic index from the data of an ```allprop``` PROPFIND, allow browsing CalDAV/CardDAV tree with a regular browser. ## REST API: using EGroupware CalDAV/CardDAV server with JSON - [Addressbook](Addressbook.md) - [Calendar](Calendar.md) (currently recurring events are readonly, they are returned but can not be created or modified) - [Mail](Mail.md) (currently only sending mails, opening interactive compose windows and vacation handling) > For the REST API you always have to send an "Accept: application/json" header and for POST & PUT requests additionally > a "Content-Type: application/json" header, otherwise you talk to the CalDAV/CardDAV server and don't get the response you expect! Following RFCs / drafts used/planned for JSON encoding of resources * [draft-ietf-jmap-jscontact: JSContact: A JSON Representation of Contact Data](https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact) ([* see at end of document](#implemented-changes-from-jscontact-draft-08)) * [draft-ietf-jmap-jscontact-vcard: JSContact: Converting from and to vCard](https://datatracker.ietf.org/doc/html/draft-ietf-jmap-jscontact-vcard/) * [rfc8984: JSCalendar: A JSON Representation of Calendar Data](https://datatracker.ietf.org/doc/html/rfc8984) ### ToDos - [x] Addressbook - [ ] update of photos, keys, attachments - [ ] InfoLog - [X] Calendar (recurring events and alarms are readonly) - [ ] support creating and modifying recurring events and alarms - [X] Mail - [ ] querying received mails - [ ] relatedTo / links - [ ] storing not native supported attributes eg. localization