2 Replies Latest reply: Mar 16, 2012 10:19 AM by Marius Bogoevici RSS

AEROGEAR-174, or overhauling server-side for Kitchensink

Marius Bogoevici Expert

Here's a summary of the service layout that I have in my mind, and largely, in the branch for Kitchensink-with-two-entities:

 

So, there would be two schemes: one JSON+full HTTP-based, one form+legacy HTTP-based as follows:

 

a) full JSON + HTTP:

 

URLConsumes/ProducesPurpose
GET /entities*/*->application/json,application/xmlGet all
GET /entities/1*/*->application/json,application/xmlGet individual entity
PUT /entities/1application/json,application/xml->*/*?, application/json,application/xmlUpdate individual entity (may return info about the entity)
POST /entitiesapplication/json,application/xml->*/*, application/json,application/xmlCreate entity
DELETE /entities/1*/*->*/*Delete entity

 

 

b) form-based + legacy HTTP

 

 

URLConsumes/ProducesPurpose
GET /entities*/*->application/json,application/xmlGet all
GET /entities/1*/*->application/json,application/xmlGet individual entity
POST /entities/1?method=_updateapplication/x-www-form-urlencoded->application/json,application/xmlUpdate individual entity (may return info about the entity)
POST /entitiesapplication/x-www-form-urlencoded->*/*, application/json,application/xmlCreate entity
POST /entities/1?method=_deleteapplication/x-www-form-urlencoded->*/*Delete entity

 

 

Major changes would be to replace the current URL-based mapping with content negociation. The current way in which they are used is optimized for access by browser, but I that a simple JS-based client that issues the request with the appropriate content-type should do the trick.

 

Another thought is whether b) can exist in a separate demo or can there be a 'legacy' page in the demo to use it.

  • 1. Re: AEROGEAR-174, or overhauling server-side for Kitchensink
    Jay Balunas Master

    Just a few comments, questions:

     

    • Do we need to support xml?
      • If it is just a simple anotation change no big deal, but lets not make structural changes for it.
      • Also lets have JSON as the default - I think that is how a) is right?
    • For b) is this required still, or as you say legacy?
      • I'm just thinking of not keeping the older approach around to make it simpler
      • Previous versions of of the app would still be available as tags.
    • Updates to quickstarts for this are still in question
      • Might want to think about this scheme for an AeroGear specific example
      • I know you already think that :-)

     

    I like the layout for documenting the interfaces btw :-)

  • 2. Re: AEROGEAR-174, or overhauling server-side for Kitchensink
    Marius Bogoevici Expert

    Jay Balunas wrote:

     

    Just a few comments, questions:

     

    • Do we need to support xml

    Not sure. It's not actually used anywhere in the example so it may just be ditched. OTOH showing content negociation for JSON/XML is something that can be done with little effort (just add the media type and weight preferences accordingly).

    My real point was to move away from separate URLs for different content types.

     

     

    • For b) is this required still, or as you say legacy?
      • I'm just thinking of not keeping the older approach around to make it simpler
      • Previous versions of of the app would still be available as tags.

    I think it's mostly legacy. May be something to show in the desktop version of the app. It's a bit spotty since it addresses the supposed lack of capabilities of the server/browser combo re:PUT/DELETE - this may or may not be a true concern since IMO the target server is known, i.e. JBoss AS - browsers, not sure.

     

    But I felt like including it for completeness, and because I believe it puts the discussion around b) in a more concrete context.

     

     

    • Updates to quickstarts for this are still in question
      • Might want to think about this scheme for an AeroGear specific example
      • I know you already think that :-)

     

    Yes, I think that bringing 'two entities' in the discussion (by me) wasn't necessary - this is something really independent of that.

     

     

     

     

    I like the layout for documenting the interfaces btw :-)

    Thanks, good feedback! Good stuff to remember when writing the Ticket Monster tutorial