Roadmap #1

lbertenasco opened this Issue Jun 12, 2013 · 4 comments


None yet

2 participants


Tip: The response is always the same: PUT User/:oid { } for each record created, obtained or modified in the operation
When only a property of a record is affected, the response will be PUT User/:oid/:property { <property_data> }

How to...

  • Insert
  • POST User { }

Into a record's collection

  • POST User/:oid/:property { }
  • POST User/*/:property { filters: ..., data: }

The push to a complex property results in a POST User/:oid/:property { } for every affected record. This leads to some potential inconsistencies since the matching records are first read to be reported as modified and may be destroyed before the updating is performed.

  • Query
  • GET User

for each record, a response

  • GET User/:oid
  • GET User { filters: , ... }
  • GET User/:oid/:property
  • GET User/*/:property { filters: , ... }
  • GET User/:oid/:property/:index
  • GET User/*/:property/:index { filters: , ... }

Other clauses alternative to "filters": limit, order, since...

  • Update
  • PATCH User/:oid { }
  • PATCH User { filters: <...>, data: }

Returns only a PATCH with the Monje referer since iterating over the complete set of results is burdensome.

  • PATCH User/:oid/:property/:index { data } < Provided the property is a composite
  • PATCH User/*/:property/:index { filters, data }
  • destroy
  • DELETE User

This results in a DELETE User as a "response". The only difference is that the later is issued with the "Monje" referer once the removal is performed.

  • DELETE User/:oid
  • DELETE User { filters: <...> }

When a record is deleted, Monje issues a DELETE. In order to avoid catching its own DELETEs, the method that processes the deletes in Monje ignores dispatches that have "Monje" (or something like that) in the Referer.

  • DELETE User/:oid/:property
  • DELETE User/*/:property { filters: ... }

Currently only "filters" (that means, no sorting, no limiting) is being supported.


A lot of routes supported yet a lot more added as well.


Some criteria for deciding what to answer:

  1. Always stay true to the MongoDB output.
  2. Return asynchronously on changes applied.
  3. Don't encumber the database with extra queries to get detailed info, make partial responses instead ( corolary of 1. )

Next version may implement a verbosity configuration to switch for optimal mode to verbose mode and force Monje to perform all queries to answer a full report of the changes made, but for now let's stick with the simplest.


This last 2 endpoints are being moved to #4 :

  • DELETE User/:oid/:property/:index < removes a record from the property, provided the property is a composite
  • DELETE User/*/:property/:index { filters }

Ready to ship!

@xaviervia xaviervia closed this Jun 13, 2013
@xaviervia xaviervia referenced this issue Jun 13, 2013

Further endpoints: Embedded Documents #4

0 of 5 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment