Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Roadmap #1

Closed
lbertenasco opened this Issue · 4 comments

2 participants

@lbertenasco
Owner

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 { }

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: ... }

@xaviervia
Owner

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

@xaviervia
Owner

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

@xaviervia
Owner

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.

@xaviervia
Owner

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
@xaviervia xaviervia referenced this issue
Open

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
Something went wrong with that request. Please try again.