{"action":"created","issue":{"url":"https://api.github.com/repos/civicrm/api4/issues/14","repository_url":"https://api.github.com/repos/civicrm/api4","labels_url":"https://api.github.com/repos/civicrm/api4/issues/14/labels{/name}","comments_url":"https://api.github.com/repos/civicrm/api4/issues/14/comments","events_url":"https://api.github.com/repos/civicrm/api4/issues/14/events","html_url":"https://github.com/civicrm/api4/issues/14","id":204757923,"number":14,"title":"Design Principles: add \"Business/Process orientated\"?","user":{"login":"ErichBSchulz","id":951298,"avatar_url":"https://avatars.githubusercontent.com/u/951298?v=3","gravatar_id":"","url":"https://api.github.com/users/ErichBSchulz","html_url":"https://github.com/ErichBSchulz","followers_url":"https://api.github.com/users/ErichBSchulz/followers","following_url":"https://api.github.com/users/ErichBSchulz/following{/other_user}","gists_url":"https://api.github.com/users/ErichBSchulz/gists{/gist_id}","starred_url":"https://api.github.com/users/ErichBSchulz/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ErichBSchulz/subscriptions","organizations_url":"https://api.github.com/users/ErichBSchulz/orgs","repos_url":"https://api.github.com/users/ErichBSchulz/repos","events_url":"https://api.github.com/users/ErichBSchulz/events{/privacy}","received_events_url":"https://api.github.com/users/ErichBSchulz/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2017-02-02T01:31:04Z","updated_at":"2017-02-13T07:30:56Z","closed_at":null,"body":"Sorry this is another hairy subjective one. But posting this get some guidance on approach and philosophy.\r\n\r\nThe current code base is essentially a CRUD wrapper around the BAOs. Is this what we see as most critical in V4? if not what is the shape of the business operations that the API needs to support and what is the pattern?\r\n\r\n### background \r\n> \"Avoid designing a REST interface that mirrors or depends on the internal structure of the data that it exposes. REST is about more than implementing simple CRUD (Create, Retrieve, Update, Delete) operations over separate tables in a relational database. The purpose of REST is to map business entities and the operations that an application can perform on these entities to the physical implementation of these entities, but a client should not be exposed to these physical details.\" \"Avoid introducing dependencies between the web API to the structure, type, or location of the underlying data sources. For example, if your data is located in a relational database, the web API does not need to expose each table as a collection of resources. Think of the web API as an abstraction of the database, and if necessary introduce a mapping layer between the database and the web API. In this way, if the design or implementation of the database changes (for example, you move from a relational database containing a collection of normalized tables to a denormalized NoSQL storage system such as a document database) client applications are insulated from these changes.\" [ref](https://docs.microsoft.com/en-us/azure/best-practices-api-design)"},"comment":{"url":"https://api.github.com/repos/civicrm/api4/issues/comments/279312899","html_url":"https://github.com/civicrm/api4/issues/14#issuecomment-279312899","issue_url":"https://api.github.com/repos/civicrm/api4/issues/14","id":279312899,"user":{"login":"eileenmcnaughton","id":336308,"avatar_url":"https://avatars.githubusercontent.com/u/336308?v=3","gravatar_id":"","url":"https://api.github.com/users/eileenmcnaughton","html_url":"https://github.com/eileenmcnaughton","followers_url":"https://api.github.com/users/eileenmcnaughton/followers","following_url":"https://api.github.com/users/eileenmcnaughton/following{/other_user}","gists_url":"https://api.github.com/users/eileenmcnaughton/gists{/gist_id}","starred_url":"https://api.github.com/users/eileenmcnaughton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/eileenmcnaughton/subscriptions","organizations_url":"https://api.github.com/users/eileenmcnaughton/orgs","repos_url":"https://api.github.com/users/eileenmcnaughton/repos","events_url":"https://api.github.com/users/eileenmcnaughton/events{/privacy}","received_events_url":"https://api.github.com/users/eileenmcnaughton/received_events","type":"User","site_admin":false},"created_at":"2017-02-13T07:30:56Z","updated_at":"2017-02-13T07:30:56Z","body":"Well - the things that are causing us to move to api v4 are not the entities you mention - they might be a trap for young players at times but it is the complex api that have coded us into a corner and create large amounts of ongoing maintenance work. As we rely on the query object for the key contact, contribution & participant api calls we have a bizarre set of things that do & don't work. Our default return properties for these include things that are not performant - especially on the contribution.get api and we have this incredible fragility due to all the per field hard-coding in the query object.\r\n\r\nI have spent around 30 hours over the last 2 months on tweaking the contribution api / search to improve performance (not finished) but the pain is all because I'm trying to deal with unpredictable code - much of it locked in by the v3 api, but other parts by the various search forms. \r\n\r\nSo, I don't mind adding additional 'business api calls' - I think these are by their nature highly individualised & ad hoc - i.e. there is a project to come up with a business approach to groups, one for tags, one for mailing events. I think these should be individual and should not block each other, or us getting rid of our major code pain point.\r\n"}}
{"actor":{"display_login":"eileenmcnaughton"}}