Hi Luiz, Getting back XML vs JSON depends on your client's Accept header. If you are using your web browser, it has a preference to accept HTTP, XHTML, XML before it wants to accept JSON. So, viewing endpoints in your browser, you'll usually get back XML.
A while back I made a video where I'm using Chrome extension Advanced Rest Client. (I also hammer the API with jmeter). Set it as: Accept: application/json https://youtu.be/FYVMGLLDAUE?t=688 ________________ Peter Dietz Longsight www.longsight.com pe...@longsight.com p: 740-599-5005 x809 On Wed, Aug 5, 2015 at 1:05 PM, Peter Dietz <pe...@longsight.com> wrote: > Hi Ondřej, > > I see that there was a code refactoring during the development, which > successfully hit the DSpaceObject endpoints ( /items, /collections, > /communities), but missed the /handle endpoint). Unintentional caching, a > bug. > The old way we were obtaining a context in REST is this (visible in handle > code). We cache a context, hold on to it, try to use it as a > singleton-ish-thing. It was supposed to be a way to help performance at one > point, your not going back to the DB to get a new context for each request, > so you could scale higher. > try { > if(context == null || !context.isValid() ) { > context = new Context(); > //Failed SQL is ignored as a failed SQL statement, > prevent: current transaction is aborted, commands ignored until end of > transaction block > context.getDBConnection().setAutoCommit(true); > } > > The problem is that you hold the same DB connection for a very long time, > and similar to a transaction, that DB connection will use the state of the > database at the time it got the connection / context. So, other edits to > objects will be missed, its caches / hold stale connection, and just sucks. > After several days of tomcat running, it could also just run into some > weird issue. > > The new DB connection that we figured out (Hat tip to Richard Rodgers at > OR2013 in PEI), is to properly get a new context for each request, and > properly close your context after each request. Wrapping everything in a > try, and finally helps ensure success. > > try > { > context = createContext(getUser(headers)); > ... > finally > { > processFinally(context); ### essentially just > context.abort() > } > > > ________________ > Peter Dietz > Longsight > www.longsight.com > pe...@longsight.com > p: 740-599-5005 x809 > > On Tue, Jul 28, 2015 at 10:04 AM, Luiz dos Santos <luiz...@gmail.com> > wrote: > >> Hi Peter, >> >> When I hit the url: >> https://demo.dspace.org/rest/handle/10673/14?expand=all it give back a >> xml instead a json? I mean, should it be a json? >> >> Thanks >> Luiz >> >> On Mon, Jul 27, 2015 at 12:37 PM, Peter Dietz <pe...@longsight.com> >> wrote: >> >>> Hi OK, >>> >>> The endpoint to look up an object by its handle is >>> <base-rest-url>/handle/<handle-number>. So, for example: >>> https://demo.dspace.org/rest/handle/10673/14?expand=all >>> >>> The /handle/<handle-number> endpoint doesn't appear to be properly >>> documented. Here is the HandleResource in the code. >>> >>> https://github.com/DSpace/DSpace/blob/master/dspace-rest/src/main/java/org/dspace/rest/HandleResource.java#L37 >>> >>> It produces a rest DSpaceObject (so if the handle yields an Item, the >>> response is a rest Item in json/xml). >>> { >>> id: 10 >>> name: "Test submit" >>> handle: "10673/14" >>> type: "item" >>> link: "/rest/items/10" >>> expand: >>> [ >>> 0] >>> lastModified: "2015-07-27 11:00:18.027" >>> ... >>> >>> ________________ >>> Peter Dietz >>> Longsight >>> www.longsight.com >>> pe...@longsight.com >>> p: 740-599-5005 x809 >>> >>> On Fri, Jul 24, 2015 at 6:54 AM, Ondřej Košarko < >>> kosa...@ufal.mff.cuni.cz> wrote: >>> >>>> Hi all, >>>> >>>> Is it currently possible, using the dspace5 rest api, to access the >>>> items/collections/communities using handles rather than internal-ids? >>>> >>>> I can see a workaround for items - first find-by-metadata-field. But >>>> that seems bit cumbersome. Handles or some other PIDs are already used to >>>> reference items*, collections, etc. and they are "guaranteed" not to >>>> change. >>>> >>>> *imagine you want to have on your personal homepage, together with PID, >>>> some other metadata for the submission. >>>> imagine you are using dc.relation.* (with PIDs as value) to link some >>>> of the submissions together and are creating a visualization of the >>>> relations. >>>> >>>> It's doable for items but there always will be at least two requests >>>> for each, or am I missing some other way? >>>> >>>> Regards, >>>> OK >>>> >>>> >>>> PS: Is it possible to have wildcards in metadataEntries? Both - keys >>>> and values? >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> DSpace-tech mailing list >>>> DSpace-tech@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >>>> List Etiquette: >>>> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >>>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> DSpace-tech mailing list >>> DSpace-tech@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/dspace-tech >>> List Etiquette: >>> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >>> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> DSpace-tech mailing list >> DSpace-tech@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/dspace-tech >> List Etiquette: >> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >> > >
------------------------------------------------------------------------------
_______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
