http testing, better json and concurrent access

java -jar thingifier-1-4-jar-with-dependencies.jar

Then localhost:4567 to see documentation.

Then start sending requests.

You can see some sample requests in the docs folder where I have projects for Insomnia and Postman.

Feature changes:

• tidied up json output to make it easier (possible) to parse,
• changed Location header to plural
• some admin urls - either see Insomnia or Postman files or the code to figure these out
• supports some concurrent access

related to 1.2

Download the .jar file and

java -jar thingifier-1-3-jar-with-dependencies.jar

To run it.

visit localhost:4567 to read the documentation and then direct traffic to its various end points as documented

e.g. http://localhost:4567/projects

Changes:

• fixed a bug I suspect was in 1.2 - could be a useful exercise to compare the relationships (hint) between 1.2 to 1.3 to see if you can find the issue interactively
• increased coverage of http api assertions and can see some other stuff in responses that needs fixed

XML and Plurals

Download the .jar file and

java -jar thingifier-1-2-jar-with-dependencies.jar

To run it.

visit localhost:4567 to read the documentation and then direct traffic to its various end points as documented

e.g. http://localhost:4567/projects

Changes:

• the app, by default now uses the plurals of entities as end points e.g. '/todos' instead of '/todo'
• 201 creation now has headers which tell you the GUID and location of created entity instance
• relationships can now be created as multi directional (this is reflected in end points and documentation)
• documentation of endpoints re-organised to be easier to read
• internal refactoring to make testing of the http api easier
• xml generation for Accept: application./xml
• responses now return instance arrays - plural by default - even for single items to make parsing easier for automating
• fixed some bugs - plenty of bugs left in there

Automated documentation generation and field validation

To run:

java -jar thingifier-1-1-jar-with-dependencies.jar

This starts up the HTTP REST API for the in built todo manager example.

Then issue commands to localhost:4567 e.g. localhost:4567/todo

Automated Documentation Generation

This release adds automatic documentation generation from the model.

When the app is running, visit http://localhost:4567/documentation in a browser to see the docs.

Constraint Validation

Also added some constraints in the model:

• mandatory fields
• field validation

Constraint validation should be performed when amending or creating instances and relationships with POST and PUT

Initial release of the app

java -jar thingifier-1-0-jar-with-dependencies.jar

App will start on port 4567.

You can then make REST API calls to localhost:4567

e.g.

• GET http://localhost:4567/todo
• GET http://localhost:4567/project

Model

Entities:

• todo
  • Fields:
    • doneStatus
    • guid
    • description
    • title
• project
  • Fields:
    • guid
    • description
    • active
    • completed
    • title
• category
  • Fields:
    • guid
    • description
    • title

Relationships:

• projects : category => project
• categories : todo => category
• todos : category => todo
• tasks : project => todo

Resulting REST API

This generates the following REST API automatically

• /todo
  • GET - all the todos
  • POST - create a todo - body JSON
  • OPTIONS
• /todo/GUID
  • GET - a specific todo
  • DELETE - a specific todo
  • POST - amend the todo
  • PUT - replace all the todo fields in the JSON body
  • OPTIONS
• /todo/GUID/categories
  • GET - all the categories for a todo
  • POST - allocate a todo to a category - body JSON must contain a GUID for a category e.g. {"guid":"1234-1234-1234-1234"}
  • POST can also be used to create a category and add it to the todo e.g. {"title":"at shops"}
    • this is probably most useful for creating a todo for a specific project e.g. /project/GUID/tasks then the json body contains the details of the todo to create and cross reference to the project using the tasks relationship

Same url pattern for /project and /category

The JSON body is simply

{"fieldname":"fieldvalue", "anotherFieldName":"anotherValue", etc.}

The fieldnames are shown in the list above for the model or the code below.

The REST API has some guards to check for 404s but very little error handling and no enforcement of mandatory fields etc.

But it is a workable API and all details are stored in memory. Clearly this means it is a rich testing target as it is possible to mess it up quite badly.

The deployed app does have some sample data for testing purposes, this can easily be DELETEd using the API.