2 Replies Latest reply on Mar 16, 2012 10:19 AM by marius.bogoevici

    AEROGEAR-174, or overhauling server-side for Kitchensink

    marius.bogoevici
    marius.bogoevici Mar 15, 2012 12:27 PM

      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.

      • 1176 Views
      • Tags:
        • 1. Re: AEROGEAR-174, or overhauling server-side for Kitchensink
          jbalunas
          jbalunas Mar 16, 2012 8:04 AM (in response to marius.bogoevici)

          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 :-)

            • Actions
          • 2. Re: AEROGEAR-174, or overhauling server-side for Kitchensink
            marius.bogoevici
            marius.bogoevici Mar 16, 2012 10:19 AM (in response to jbalunas)

            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

              • Actions