...

This page is just being used by the author to record his thoughts/progress towards a REST Service Implementation for Ofbiz. Note this document is a work in progress. I'm still learning about REST as well, so this document may be inaccurate.

Why?

TODO

How?

Base url: https://localhost/webtools/control/RESTService/

Use similar implementation to SOAP and the SoapEventHandler (i.e. implement a RestEventHandler)

Options:

1) Service definitions The service definitions could be extended to contain extra metadata. This metadata would could be used to generate the WADL:

CRUD - CREATE

    <service name="createPerson" engine="java" default-entity-name="Person"
            location="org.ofbiz.party.party.PartyServices" invoke="createPerson" 
            auth="false">
        <description>Create a Person</description>

" export="true" 
            <restrest-export resource-name="person" method-name="create" 
            rest-http-method="PUT,POST">


            >
        <description>Create </rest-export>a Person</description>

        <auto-attributes mode="IN" include="pk" optional="true"/>
        <auto-attributes mode="OUT" include="pk" optional="false"/>
        <auto-attributes mode="IN" include="nonpk" optional="true"/>
        <attribute name="preferredCurrencyUomId" type="String" mode="IN" optional="true"/>
        <attribute name="description" type="String" mode="IN" optional="true"/>
        <attribute name="externalId" type="String" mode="IN" optional="true"/>
        <attribute name="statusId" type="String" mode="IN" optional="true"/>
    </service>

The above service would be accessed at the url:

https://localhost/webtools/control/RESTService/person - where person = rest-resource-name in the service definition.

Note that the service can be accessed by PUT and POST. This is to allow a kludge for clients such as Flex that don't understand PUT.

There could be a single parameter passed to the PUT, which would be the map-Map xml document (text/xml) which would be the same document as would be passed in to the equivalent SOAPService. Alternatively, the parameters could be passed in as text/plain parameters. Question: which would be better? ... text/xml map-Map may be easier to implement whereas text/plain may be simpler for the client.

Similar to the request parameter(s), the response could be the map-Map document, or it may be possible to map service errors back to http response codes. The map-Map text/xml response would be the simplest to implement. We could event implement both response types. If we implemented both, the response to the client would be dependent on whether an accept="text/xml" or accept="text/plain" was sent by the client with the initial request.

CRUD - READ

TODO

CRUD - UPDATE

TODO

CRUD - DELETE

TODO2) Create additional Resource based service definitions that map to existing services.