I think consolidating the V2 clients into one makes more sense so that the migration path becomes easier and the rewrite is relatively easier.
+1 on creating a migration guide/doc. On 2/14/17, 1:45 AM, "Ismaël Mejía" <[email protected]> wrote: >Thanks everyone for answering, > >Having a single endpoint seems to me as a good idea as well as other >improvements, and I know this project is incubating so breaking changes are >easier to do at this moment. > >@Apporv I don't think that achieving backward compatibility (if not >complete at least at the most possible) is going to be easy, but if you >guys achieve this it would be great!. > >I just skimmed through the new code and tested our current integration with >Atlas (that uses the V1 client) and most things break because of the move >from Referenceable to AtlasEntity as well as other type changes, I >understand that this is a new API, but have you guys considered documenting >a migration path (at least for the breaking changes), also I understand >that API improvements are welcome, but users may expect atlas-client be the >place to have a more stable API contract and so many changes are going >there, that I have the impression that basically a full rewrite is needed >for the users (even if it is a simple rewrite). > >Regards, >Ismaël > >On Thu, Feb 9, 2017 at 7:37 PM, Apoorv Naik <[email protected]> wrote: > >> 1. The V2 APIs have introduced strong typed REST interfaces like >> TypesREST, EntityREST etc. The main motive is cleanup and providing more >> clarity on what kind of data is being transmitted over the wire rather that >> just saying that the resource method will return a JSON (which is implied). >> 2. Also the V2 APIs aim to reduce the current complexity of the type >> system (which seem to have a great influence from Scala and the underlying >> DB) >> 3. The client code was split into smaller pieces in order to reduce the >> code in the existing client classes. Lot of refactoring has went in the >> client code to allow easy extension, a couple of bugs/side-effects (retries >> more that expected number while testing) from older code were fixed. >> >> @Ismael: I think for backward compatibility the AtlasClient (v1) shouldn’t >> change instead once the V2 APIs undergo rigorous test cycles we should wire >> ALL the V1 endpoints to talk to the new code. >> @JB: Can you share what changes/improvements you have in mind ? >> >> >> >> On 2/8/17, 9:06 AM, "Jean-Baptiste Onofré" <[email protected]> wrote: >> >> >Hi Ismael >> > >> >I started a bunch of change in the rest client that I would like to >> propose. All changes should be backward compatible. Not sure it will end in >> 0.8 anyway. >> > >> >Regards >> >JB >> > >> >On Feb 8, 2017, 10:41, at 10:41, "Ismaël Mejía" <[email protected]> >> wrote: >> >>Hello, >> >> >> >>I tried to create a new entity (a kafka topic) using the new option in >> >>the >> >>Search pane and it shows an error "Something went wrong". Is this >> >>already >> >>reported ? >> >> >> >>Looking at the request it seems to be an error 500, I tried to >> >>reproduce it >> >>with >> >>the JSON and curl but I got always an error, is there any document >> >>available >> >>about the API v2 what's improved in particular? >> >> >> >>And finally, I noticed that there are new clients for each endpoint in >> >>the >> >>atlas-client codebase, is the traditional AtlasClient going to be >> >>changed so >> >>that it uses all the new endpoints before the 0.8 release ? >> >> >> >>Thanks, >> >>Ismaël Mejía >> >>
