Hi Frank
I always get PUT and POST mixed up. So, if all the GET/POST was GET/PUT
instead, would that be sufficient. Or should all the PUT/DELETE be
POST/DELETE also?
If i say:
PUT is used for "putting" some content onto the url
POST is used for when I want to create something new
Is that correct, then? To create an empty object with a given
pid /objects/{pid} would I use PUT or a POST?
Regards
On Tue, 2009-10-27 at 15:06 +0100, Schwichtenberg, Frank wrote:
> Hello Asgar,
> I don't agree with "GET/POST". Talking about Representational State Transfer
> and refer to the same URL by both operations I would assume that I GET the
> same representation which I can use for "writing". Then it is a PUT not a
> POST.
>
> I know, it is very risky to post such a statement to a mailing-list. But I
> believe in it. ;-)
>
> From RFC 2616: "The POST method is used to request that the origin server
> accept the entity enclosed in the request as a new subordinate of the
> resource identified by the Request-URI in the Request-Line."
> I think "subordinate" is the point.
>
> Regards, Frank
>
> > -----Ursprüngliche Nachricht-----
> > Von: Asger Askov Blekinge [mailto:a...@statsbiblioteket.dk]
> > Gesendet: Dienstag, 27. Oktober 2009 14:51
> > An: fedora-commons-developers@lists.sourceforge.net
> > Betreff: [Fedora-commons-developers] Fedora REST interface,a proposal
> > for methods
> >
> > Hi
> >
> > For Fedora3.3, it seems we just want to duplicate the methods in the
> > SOAP interface, but there are room for improvement, perhaps in a later
> > version.
> >
> > Here are some ideas I have been thinking on.
> >
> > OBJECTS
> >
> > * GET /objects/{pid} - gets some presentation of the object like
> > objectprofile today
> > * PUT /objects/{pid} - Create a new object, with no content, and
> > default values
> >
> > * DELETE /objects/{pid} - purge the object
> >
> > * GET/POST /objects/{pid}/label - read/write the object label
> >
> > * GET/POST /objects/{pid}/state - read/write the object state
> >
> > * GET /objects/{pid}/datastreams - get a list of the datastreams IDs
> >
> > * GET /objects/{pid}/contentmodels - Get the content models of the
> > object
> >
> > * POST /objects/{pid}/contentmodels/{cmid} - Add a content model to
> > the
> > object
> >
> >
> >
> > RELATIONS
> >
> > * GET/POST /objects/{pid}/relations - read/write the content of the
> > RELS-EXT datastream
> >
> > * PUT/DELETE /objects/{pid}/relations/{relationname}/to/{objID} -
> > add/delete relation
> >
> >
> > DATASTREAMS
> > * PUT/DELETE /objects/{pid}/datastreams/{dsID}
> >
> > * GET/POST /objects/{pid}/datastreams/{dsID} read/write the contents
> > of
> > a datastream
> >
> > * GET /objects/{pid}/datastreams/{dsID}/properties - get the
> > properties
> > in some format
> >
> > * GET/POST /objects/{pid}/datastreams/{dsID}/properties/label -
> > read/write the label of the datastream
> >
> > * GET/POST /objects/{pid}/datastreams/{dsID}/properties/versionable
> >
> > * GET/POST /objects/{pid}/datastreams/{dsID}/properties/state
> >
> > * GET/POST /objects/{pid}/datastreams/{dsID}/properties/checksum
> >
> > * GET/POST /objects/{pid}/datastreams/{dsID}/properties/mimetype
> >
> > * GET/POST /objects/{pid}/datastreams/{dsID}/properties/formatURI
> >
> > * GET/POST /objects/{pid}/datastreams/{dsID}/properties/relations -
> > read/write the content of the RELS-INT datastream specific to this
> > datastream
> >
> > *
> > PUT/DELETE
> > /objects/{pid}/datastreams/{dsID}/properties/relations/{relationname}/t
> > o/{objID} - add/delete relation
> >
> >
> > * GET /objects/{pid}/datastreams/{dsID}/properties/versions - list of
> > versions
> >
> > * GET /objects/{pid}/datastreams/{dsID}/properties/versions/{datetime}
> > - get the contents of the datastream at the datetime
> >
> > *
> > GET
> > /objects/{pid}/datastreams/{dsID}/properties/versions/{datetime}/proper
> > ties - get the properties in some format
> > and so on like above
> >
> >
> >
> > This would provide a, in my view, intuitive interface to Fedora. Every
> > property is reachable with a simple URL, nothing should require parsing
> > of output. Objects can be created without ingest, and populated.
> > Contentmodels become easily reachable through the interface, and
> > relations
> >
> >
> > Regards
> >
> >
> >
> >
> > -----------------------------------------------------------------------
> > -------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Fedora-commons-developers mailing list
> > Fedora-commons-developers@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
>
> -------------------------------------------------------
>
> Fachinformationszentrum Karlsruhe, Gesellschaft für
> wissenschaftlich-technische Information mbH.
> Sitz der Gesellschaft: Eggenstein-Leopoldshafen, Amtsgericht Mannheim HRB
> 101892.
> Geschäftsführerin: Sabine Brünger-Weilandt.
> Vorsitzender des Aufsichtsrats: MinR Hermann Riehl.
>
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
