I agree, the human-UI needs to be optimized for an elegant UX, the API needs to be kept logically simple.
For the API, you should be able to automate a lot of the CRUD renderings by introspection on your db structure, equivalent to how Rails/Django auto-generate an admin interface. For more details, I suggest you read RESTful Web Services. http://webseitz.fluxent.com/wiki/RestfulWebServices On Mon, May 7, 2012 at 8:44 AM, Jonathan Vanasco <[email protected]>wrote: > i generally hate this approach to web programming. > > i find it very shortsighted and unmanageable for those you're trying > to service - if you change your website, the API more often than not > causes apps to break. i see this popular in the rails community where > not many projects last long. > > if you're making something for machines, i'd suggest creating a > versioned API. if you're up go /v3/function, old clients can still > hit /v1/function and not break. > > in terms of structure, you could cut this a number of ways > - use matchdicts and multiple view_configs to have everything operate > on a single handler/function , and change the output within the > function > - use multiple urls/handlers that all call an internal API/Library > function. > - a lot of other options > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
