Versie beheer Web API

[PdeBie]

Hoi allen,

een compleet nieuwe uitdaging voor mij, ik mag een API (op basis van .NET Web API) gaan bouwen.

Doel van deze API is o.a. het opvragen van data voor onze interne applicaties en voor derde partijen waar wij mee samenwerken. Bijvoorbeeld informatie over onze leden.

Omdat het een API betreft waar meerdere partijen gebruik van gaan maken kan je niet bij elke update lukraak de oude versie offline halen, omdat die andere partijen dan wellicht in de problemen komen. Er zullen dus meerdere versies naast elkaar moeten komen te draaien, bijvoorbeeld domein/v1.0.0/..... en domein/v1.1.0/...... De andere partijen krijgen dan bij een nieuwe versie documentatie opgestuurd met de wijzigingen die zij moeten doen om van de nieuwe versie gebruik te kunnen maken. Die workflow is allemaal te hanteren.

Wat voor mij echter helemaal nieuw is, hoe versiebeheer als dit in Visual Studio te kunnen hanteren. Wij gebruiken momenteel Visual Studio 2012 en 2013 met (helaas) Visual SourceSafe 2005, maar voor dit project kijk ik liever naar iets anders, want ik zie dit in SourceSafe niet echt lukken. Ik heb echter nog totaal geen ervaring met andere "source control" systemen.

Wat is jullie ervaring hierin? Wat kunnen jullie me adviseren om dit soort versiebeheer makkelijk beheersbaar te houden? Het liefst moet het te integreren zijn in Visual Studio.

Daarnaast, hoe gaan jullie om met hotfixes?
Stel je hebt versie 1.1.0 en versie 1.2.0 draaien en nu blijkt er een kritische bug ontdekt te zijn die in beide versies optreedt. Dan zou je dus naar versie 1.1.1 en versie 1.2.1 moeten gaan. Hoe passen jullie dit toe?

In ieder geval alvast bedankt voor het meedenken.

[Afvalzak]

Ik zou me even verdiepen in Branching(Wikipedia: Branching (revision control)). De tools waarmee je dat kan doen zijn o.a.:
Git
SVN
TFS (Betaald natuurlijk)

[dinux]

Mercurial is ook nog een optie.

Volgens mij werkt VS het beste met SVN, maar ik heb nooit GIT gebruikt voor een .NET project.

[Merethil]

pdebie schreef op dinsdag 20 mei 2014 @ 10:16:
Hoi allen,

een compleet nieuwe uitdaging voor mij, ik mag een API (op basis van .NET Web API) gaan bouwen.

Doel van deze API is o.a. het opvragen van data voor onze interne applicaties en voor derde partijen waar wij mee samenwerken. Bijvoorbeeld informatie over onze leden.

Omdat het een API betreft waar meerdere partijen gebruik van gaan maken kan je niet bij elke update lukraak de oude versie offline halen, omdat die andere partijen dan wellicht in de problemen komen. Er zullen dus meerdere versies naast elkaar moeten komen te draaien, bijvoorbeeld domein/v1.0.0/..... en domein/v1.1.0/...... De andere partijen krijgen dan bij een nieuwe versie documentatie opgestuurd met de wijzigingen die zij moeten doen om van de nieuwe versie gebruik te kunnen maken. Die workflow is allemaal te hanteren.

Wat voor mij echter helemaal nieuw is, hoe versiebeheer als dit in Visual Studio te kunnen hanteren. Wij gebruiken momenteel Visual Studio 2012 en 2013 met (helaas) Visual SourceSafe 2005, maar voor dit project kijk ik liever naar iets anders, want ik zie dit in SourceSafe niet echt lukken. Ik heb echter nog totaal geen ervaring met andere "source control" systemen.

Wat is jullie ervaring hierin? Wat kunnen jullie me adviseren om dit soort versiebeheer makkelijk beheersbaar te houden? Het liefst moet het te integreren zijn in Visual Studio.

Daarnaast, hoe gaan jullie om met hotfixes?
Stel je hebt versie 1.1.0 en versie 1.2.0 draaien en nu blijkt er een kritische bug ontdekt te zijn die in beide versies optreedt. Dan zou je dus naar versie 1.1.1 en versie 1.2.1 moeten gaan. Hoe passen jullie dit toe?

In ieder geval alvast bedankt voor het meedenken.

Waarom zou je je API niet gewoon backwards compatible houden?
Uiteindelijk kan je gewoon nieuwe functies toevoegen en elke keer een update uitbrengen. Mocht je een functie willen vervangen / aanpassen maak je hem deprecated en geef je dit door aan iedereen, daarna maak je, twee versies later, de aanpassing voor die specifieke functie.
Als dat te lang duurt kan je altijd twee functies met soortgelijke opties maken en ze naast elkaar draaien, de ene deprecaten en de andere de "nieuwe standaard" laten zijn.

Hoe dan ook: voor je vraag kan ik aanraden gewoon te gaan werken met branches in SVN of Git. Dit is niet lastig om te implementeren en het voordeel is dat je altijd goed onderscheid hebt tussen je verschillende versies die je onderhoudt, terwijl je ook de main branch kan aanpassen en doorvoeren naar al je branches.

[ Voor 6% gewijzigd door Merethil op 20-05-2014 10:26 ]

[PdeBie]

Verhaal van die branches is me nog niet helemaal duidelijk, maar zal daar eens wat over gaan lezen.
Je hebt dus als het ware 1 main branche (die term verschilt per sourcecontrol (SVN/GIT/etc.) schijnt) waar je constant op ontwikkeld. Deze main branche is dan de leidraad voor de nieuw te releasen versie. Begrijp ik het zo goed?

Hoe ga je dan bijvoorbeeld om met zo'n hotfix als ik aangaf? Die dus een bug aanpakt die zowel in de huidige als een eerdere versie voorkomt?

De API backwards compatible houden heb ik ook aan zitten denken, maar ik vermoed dat dit op de langere termijn (als de API ook groter wordt) steeds minder overzichtelijk wordt.

Daarnaast hebben wij vrij grote partijen waar we mee samenwerken, dat we er niet vanuit kunnen gaan dat ze aanpassingen even snel door kunnen voeren als dat wij dat kunnen i.v.m. compatibiliteit met interne applicaties aan hun kant etc.

Maar nogmaals, ik ben vrij nieuw op het gebied van (fatsoenlijk) versiebeheer, dus alle tips zijn welkom

[curvemod]

pdebie schreef op dinsdag 20 mei 2014 @ 10:16:
Omdat het een API betreft waar meerdere partijen gebruik van gaan maken kan je niet bij elke update lukraak de oude versie offline halen, omdat die andere partijen dan wellicht in de problemen komen. Er zullen dus meerdere versies naast elkaar moeten komen te draaien, bijvoorbeeld domein/v1.0.0/..... en domein/v1.1.0/...... De andere partijen krijgen dan bij een nieuwe versie documentatie opgestuurd met de wijzigingen die zij moeten doen om van de nieuwe versie gebruik te kunnen maken. Die workflow is allemaal te hanteren.

Los van je vraag is versoning in een url sowieso een bad practice, ik zou de HTTP Accept header daar voor inzetten, zie bijvoorbeeld hoe de Github API dat doet: https://developer.github.com/v3/media/.

Ik ben wel gecharmeerd van een versiebeheer in GIT, losjes gebaseerd op dit idee -> http://www.acquia.com/blo...re-git-branching-strategy.

Dus je ontwikkeld tegen een development branch aan, iedere feature wordt in een aparte branch gemaakt en na een review (in een pull request) teruggemerged naar development. Iedere keer als je een nieuwe versie maakt ga je naar een release branch, daar maak je een tag op en je doet de release. Hotfixes worden direct op de release branch gemaakt. Er wordt een nieuwe tag gemaakt op release en gereleased. Daarna release weer terugmergen op development.

[ Voor 26% gewijzigd door curvemod op 20-05-2014 10:38 ]

[Merethil]

pdebie schreef op dinsdag 20 mei 2014 @ 10:32:
Verhaal van die branches is me nog niet helemaal duidelijk, maar zal daar eens wat over gaan lezen.
Je hebt dus als het ware 1 main branche (die term verschilt per sourcecontrol (SVN/GIT/etc.) schijnt) waar je constant op ontwikkeld. Deze main branche is dan de leidraad voor de nieuw te releasen versie. Begrijp ik het zo goed?

Hoe ga je dan bijvoorbeeld om met zo'n hotfix als ik aangaf? Die dus een bug aanpakt die zowel in de huidige als een eerdere versie voorkomt?

De API backwards compatible houden heb ik ook aan zitten denken, maar ik vermoed dat dit op de langere termijn (als de API ook groter wordt) steeds minder overzichtelijk wordt.

Daarnaast hebben wij vrij grote partijen waar we mee samenwerken, dat we er niet vanuit kunnen gaan dat ze aanpassingen even snel door kunnen voeren als dat wij dat kunnen i.v.m. compatibiliteit met interne applicaties aan hun kant etc.

Maar nogmaals, ik ben vrij nieuw op het gebied van (fatsoenlijk) versiebeheer, dus alle tips zijn welkom

Ik denk dat backwards compatibility geen probleem hoeft op te leveren: Je blijft gewoon een aantal versies lang de functies aanbieden die deprecated zijn en geeft bij elke update aan welke functies zullen verdwijnen/verschijnen. Voordeel is dat je klanten wat meer tijd kunnen nemen om te "upgraden".
In dat opzicht zie ik een zelfgeschreven API niet anders dan de set standaardfuncties in programmeertaal X. Neem bijvoorbeeld PHP of Java: Ze hebben een aantal deprecated functies die je gewoon kan blijven gebruiken, maar na een aantal jaar (of vanaf versie X) zal je de aanpassing moeten maken wil je bijblijven.

-edit- Hier stond iets nutteloos voor nu

[ Voor 9% gewijzigd door Merethil op 20-05-2014 10:40 ]

[Marcj]

Tip om eens te lezen over hoe men dit ook wel doet: http://nvie.com/posts/a-successful-git-branching-model/

Dit is wel op basis van git, maar in principe generiek toepasbaar.

[PdeBie]

jhuiting schreef op dinsdag 20 mei 2014 @ 10:34:
[...]
Dus je ontwikkeld tegen een development branch aan, iedere feature wordt in een aparte branch gemaakt en na een review (in een pull request) teruggemerged naar development. Iedere keer als je een nieuwe versie maakt ga je naar een release branch, daar maak je een tag op en je doet de release. Hotfixes worden direct op de release branch gemaakt. Er wordt een nieuwe tag gemaakt op release en gereleased. Daarna release weer terugmergen op development.

En dan de 2 onder de 5 steken, boer er bovenop, elleboog op tafel, jack in the box. STIFT!
(afgeleid van: http://www.youtube.com/watch?v=hZBHkJFcYII met mij in de rol van Edgar in dit geval )

Sorry, maar dit stukje is echt nog totale abracadabra voor me.

@Marcj: dank je. zal dat stukje ook eens rustig doornemen

[ Voor 3% gewijzigd door PdeBie op 20-05-2014 10:54 ]

[Woy]

pdebie schreef op dinsdag 20 mei 2014 @ 10:16:
Wat voor mij echter helemaal nieuw is, hoe versiebeheer als dit in Visual Studio te kunnen hanteren. Wij gebruiken momenteel Visual Studio 2012 en 2013 met (helaas) Visual SourceSafe 2005, maar voor dit project kijk ik liever naar iets anders, want ik zie dit in SourceSafe niet echt lukken. Ik heb echter nog totaal geen ervaring met andere "source control" systemen.

Kijk het is een goed plan om van Visual SourceSafe af te stappen, want dat is inderdaad een hopeloos (verouderd) product, maar ik zie niet in waarom dit niet in SourceSafe zou kunnen. SourceSafe ondersteunt ook gewoon de benodigdheden om meerdere versies naast elkaar te ontwikkelen.

Verder voor source control in VS kun je inderdaad kijken naar SVN, TFS of Git. Voor alle drie is er in de nieuwe versies van VS gewoon ondersteuning ( SVN via een plugin als AnkhSVN ). En hoewel IDE integratie inderdaad handig is, is het IMHO echt geen vereiste. Voor bijvoorbeeld Git zul je voor complexe acties alsnog terug moeten vallen op de command line.

Als je nu gaat kijken voor een nieuw VCS zou ik persoonlijk voor Git kiezen, aangezien dat erg breed gedragen wordt, en het decentrale karakter vindt ik erg fijn werken.

@TS: Zo te zien mis je gewoon de basiskennis van version control, dus ik zou eerst eens iets meer basis informatie proberen op te doen. Er is volgens mij een gratis EBook "Version Control by Example" die je eens zou kunnen lezen. De strategie van Git die hierboven is genoemd vind ik ook erg fijn werken.

[ Voor 10% gewijzigd door Woy op 20-05-2014 10:59 ]

[curvemod]

pdebie schreef op dinsdag 20 mei 2014 @ 10:53:
Sorry, maar dit stukje is echt nog totale abracadabra voor me.

Ik snap 'm het is een beetje kort door de bocht, ben helaas ook nog aan het werk. Zal het vanavond wel even iets duidelijker uittypen. Misschien dat dit plaatje (uit het artikel hierboven) het duidelijker maakt, zou die beide artikelen even lezen (artikel wat ik linkte is vervolg op andere artikel).

[RobIII]

Afvalzak schreef op dinsdag 20 mei 2014 @ 10:20:
TFS (Betaald natuurlijk)

Je kunt tot 5 gebruikers TFS online gratis gebruiken

[ Voor 26% gewijzigd door RobIII op 20-05-2014 11:11 ]

[TheNephilim]

Alle Git tips die ik hier voorbij zie komen zijn inderdaad erg handig! Heb me zelf ook enigszins verdiept in git flow en SourceTree heeft er zelfs 'ondersteuning' voor. Ik heb niet echt veel projecten waar ik meer nodig heb dan master & develop, maar voor de wat grotere en permanente projecten is het wel erg handig!

Wat betreft je url, ik zou /api/v1 en /api/v2 gebruiken voor je major versies. Die zullen waarschijnlijk niet compatibel meer zijn met de vorige. Je minors (1.1.x) en patches/hotfixes (1.1.1) moeten dan wel compatibel zijn met elkaar, maar dat lijkt me ook erg handig voor de gebruikers van je API.

[HMS]

Misschien off-topic, maar zeker wel handig: kijk eens naar HATEOAS: http://www.slideshare.net/trilancer/why-hateoas-1547275

[Kettrick]

TheNephilim schreef op dinsdag 20 mei 2014 @ 11:38:
Wat betreft je url, ik zou /api/v1 en /api/v2 gebruiken voor je major versies. Die zullen waarschijnlijk niet compatibel meer zijn met de vorige. Je minors (1.1.x) en patches/hotfixes (1.1.1) moeten dan wel compatibel zijn met elkaar, maar dat lijkt me ook erg handig voor de gebruikers van je API.

Dit gebruiken wij hier ook, API versies staan totaal los van applicatie releases. Ik gehele backends vervangen maar dezelfde API's behouden; en omgekeerd geheel nieuwe API's opgebouwd om bestaande applicaties.

Ik zou dus ook gewoon verschillende endpoints binnen één applicatie implementeren, waarbij je je gehele V1 en V2 model apart houdt.

Oude server artifacts behouden en beheren in verschillende branches is een slecht idee en dat gaat je na verloop van tijd ontzettend veel tijd kosten.

Wij draaien 100+ micro services die vrijwel allemaal de bovenstaande structuur hebben

[InZane]

RobIII schreef op dinsdag 20 mei 2014 @ 11:11:
[...]

Je kunt tot 5 gebruikers TFS online gratis gebruiken

Dat ^^
En TFS heeft tegenwoordig ook GIT ondersteuning.

[raptorix]

jhuiting schreef op dinsdag 20 mei 2014 @ 10:34:
[...]

Los van je vraag is versoning in een url sowieso een bad practice, ik zou de HTTP Accept header daar voor inzetten, zie bijvoorbeeld hoe de Github API dat doet: https://developer.github.com/v3/media/.

Ik ben wel gecharmeerd van een versiebeheer in GIT, losjes gebaseerd op dit idee -> http://www.acquia.com/blo...re-git-branching-strategy.

Dus je ontwikkeld tegen een development branch aan, iedere feature wordt in een aparte branch gemaakt en na een review (in een pull request) teruggemerged naar development. Iedere keer als je een nieuwe versie maakt ga je naar een release branch, daar maak je een tag op en je doet de release. Hotfixes worden direct op de release branch gemaakt. Er wordt een nieuwe tag gemaakt op release en gereleased. Daarna release weer terugmergen op development.

Wij doen het iets anders, wij gebruiken het GIT flow model, belangrijkste verschil is dat je hotfixes doet op de Master, het is dus ook belangrijk om te zorgen dat je je release branche na de test fase terugmerged op de Master, kortom: Master is altijd gelijk aan je Productie.

http://nvie.com/posts/a-successful-git-branching-model/

Edit: was hierboven ook al genoemd

[Avalaxy]

Versioning in je VCS is een optie. Een andere optie is al je business logic weg abstracten in een aparte layer (zou je sowieso moeten doen, maar voor het geval je dat niet gedaan had), dan 2 controllers maken (bv. UserV1Controller en UserV2Controller) die gebruik maken van deze business logic, en dan met attribute routing aangeven bij welke versie je controller hoort. Voorbeeldje hiervan: http://www.asp.net/web-ap...bute-routing-in-web-api-2.

[Refro]

Woy schreef op dinsdag 20 mei 2014 @ 10:57:
[...]

Kijk het is een goed plan om van Visual SourceSafe af te stappen, want dat is inderdaad een hopeloos (verouderd) product, maar ik zie niet in waarom dit niet in SourceSafe zou kunnen. SourceSafe ondersteunt ook gewoon de benodigdheden om meerdere versies naast elkaar te ontwikkelen.

Mijn ervaring met branches in VSS is dat het ongeveer net zo goed werkt als handmatig beheer met zip files. Ook het sharen van files is een ramp omdat geen ander versie beheer systeem dit ondersteund.

Ik hoor hier iedereen over SVN, TFs, Git en Hg praten. Maar in mijn ogen is het belangrijker eerst een omschreven versie strategie te hebben en dit hierna in een van de tools te implementeren.

Zelf hebben we omschreven wanneer een letter, major of minor cijfer dient te wijzigen. Dit hebben we vervolgens geimplementeerd in zip files beheer, VSS en nu in SVN (alles zit nu minimaal in VSS en nieuwe dingen in SVN). Zip is iets van het verleden maar we kunnen elke uitgebrachte versie tot ergens midden jaren 80 oplepelen.

[DiedX]

Wat bedoel je met sharen van files? Dit klinkt als een bundle...

[PdeBie]

Refro schreef op woensdag 21 mei 2014 @ 08:18:
[...]

Ik hoor hier iedereen over SVN, TFs, Git en Hg praten. Maar in mijn ogen is het belangrijker eerst een omschreven versie strategie te hebben en dit hierna in een van de tools te implementeren.

Uiteraard. Daar moeten we hier ook nog over nadenken. Wat in de TS staat is ook maar een voorbeeld. Gaat me meer om hoe je dit zou kunnen hanteren in je code en sourcecontrol.

Ik heb vandaag overleg met mijn manager over dit onderwerp en zal het verhaal van branching eens aankaarten.

[Anima-t3d]

Tip: Als je GIT in Visual Studio wilt gebruiken, zou ik GIT Extensions gebruiken (werkt ook buiten VS om)

Source: https://github.com/gitextensions/gitextensions
Download: MSDN: Git Extensions

[Woy]

Refro schreef op woensdag 21 mei 2014 @ 08:18:
[...]
Mijn ervaring met branches in VSS is dat het ongeveer net zo goed werkt als handmatig beheer met zip files. Ook het sharen van files is een ramp omdat geen ander versie beheer systeem dit ondersteund.

Hoewel het inderdaad echt niet fijn werkt, is het best mogelijk om alle benodigde acties er in te doen.

Ik hoor hier iedereen over SVN, TFs, Git en Hg praten. Maar in mijn ogen is het belangrijker eerst een omschreven versie strategie te hebben en dit hierna in een van de tools te implementeren.

Dat is inderdaad exact het punt dat ik wil maken. Als Branches voor de TS al iets vreemds zijn voor de TS, dan schort er vooral iets aan de hele versie beheer strategie. Dat los je niet alleen op door een andere tool te gaan gebruiken ( Dat maakt het overigens wel veel makkelijker )

Anima-t3d schreef op woensdag 21 mei 2014 @ 08:56:
Tip: Als je GIT in Visual Studio wilt gebruiken, zou ik GIT Extensions gebruiken (werkt ook buiten VS om)

GIT heeft in VS 2013 ( volgens mij ook 2012, maar dat weet ik niet zeker ) ook native ondersteuning. Ik zou inderdaad nog wel een tool als SourceTree aanraden om ook buiten VS om GIT acties uit te kunnen voeren.

[Refro]

DiedX schreef op woensdag 21 mei 2014 @ 08:42:
Wat bedoel je met sharen van files? Dit klinkt als een bundle...

Met sharen in VSS kun je dezelfde file binnen meerdere branches hebben. Als je hem dan in 1 branch aanpast is ie na "check-in" in alle branches aangepast.

[Grodor]

Avalaxy schreef op dinsdag 20 mei 2014 @ 21:09:
Versioning in je VCS is een optie. Een andere optie is al je business logic weg abstracten in een aparte layer (zou je sowieso moeten doen, maar voor het geval je dat niet gedaan had), dan 2 controllers maken (bv. UserV1Controller en UserV2Controller) die gebruik maken van deze business logic, en dan met attribute routing aangeven bij welke versie je controller hoort. Voorbeeldje hiervan: http://www.asp.net/web-ap...bute-routing-in-web-api-2.

Ik zou inderdaad ook wanneer het kan gaan voor bovenstaande optie. Dan hoef je namelijk niet meerdere sites naast elkaar te draaien.

Ik ben mijzelf op dit moment ook aan het oriënteren en kwam het scheiden van versies d.m.v. namespaces tegen. http://blogs.msdn.com/b/webdev/archive/2013/03/08/using-namespaces-to-version-web-apis.aspx.

Er wordt echter ook in de comments (en in dit topic) genoemd dat versioning via de URL geen goede optie is. Wat ook onderbouwd wordt door de volgende persoon: http://codebetter.com/howarddierking/2012/11/09/versioning-restful-services/

Wellicht is een combinatie mogelijk ? Ik weet niet in hoeverre het mogelijk is om te routen op headers.

[Grijze Vos]

Verplichte kost in deze zaak is om even Semantic Versioning door te lezen. En daarnaast je goed te realiseren dat API stabiliteit ontzettend belangrijk is. Denk dus goed na over wat je exposed en hoe.

Als je ervoor zorgt dat je met semantic versioning werkt, dan hoef je iig maar 1 URI per major release up te houden.

[raptorix]

Anima-t3d schreef op woensdag 21 mei 2014 @ 08:56:
Tip: Als je GIT in Visual Studio wilt gebruiken, zou ik GIT Extensions gebruiken (werkt ook buiten VS om)

Source: https://github.com/gitextensions/gitextensions
Download: MSDN: Git Extensions

Wij werken hier eigenlijk allemaal gewoon met de Sourcetree, ook wel geexperimenteerd met visual studio plugins, maar de meerwaarde is eigenlijk nihil.

[Anima-t3d]

raptorix schreef op woensdag 21 mei 2014 @ 10:44:
Wij werken hier eigenlijk allemaal gewoon met de Sourcetree, ook wel geexperimenteerd met visual studio plugins, maar de meerwaarde is eigenlijk nihil.

Had ik nog niet van gehoord, maar ziet er inderdaad wel netjes uit!

[raptorix]

Anima-t3d schreef op woensdag 21 mei 2014 @ 12:59:
[...]

Had ik nog niet van gehoord, maar ziet er inderdaad wel netjes uit!

Goed om te horen
Er zijn bepaalde specifieke GIT commando's nog niet ondersteunt, maar dat zijn dan wel de exotische dingen.

[HMS]

SourceTree is de enige (gratis) GUI voor Git waar je als power user ook wat mee kan. Github for Windows is iets te simplistisch en is beter geschikt voor een SVN achtige workflow. Dingen als 'force push' en 'interactive rebase' ondersteund SourceTree nog niet vanuit de GUI, maar de console is ook maar 1 klik verderop

Maar, volgens mij ging deze thread niet over de tools om mee te Gitten

[PdeBie]

Inmiddels hier een aantal stappen verder.

Besloten is om de API toch backwards compatible te maken. Gezien de hoeveelheid updates die we verwachten, was dit makkelijker te beheren dan wat we in eerste instantie wilden.

Wel gaan we kijken naar een nieuwe sourcecontrol in plaats van SourceSafe, maar welke dat wordt zijn we nog niet over uit.

[Lethalis]

Ik ben persoonlijk erg te spreken over Git. Voor de rest sluit ik mij aan bij het verhaal van sommige anderen hier om alleen per major release een URL te gebruiken (v1, v2, etc) en de minor's compatible te houden.

Op kantoor gebruiken we helaas ook SourceSafe. Dat komt omdat we ook veel Windows.Forms development doen en de project files nauwelijks te mergen zijn op een goede manier. Hier zijn uiteraard wel tools voor, maar ik ben bang dat dit de eenvoud die we nu hebben in de weg staat (hoewel locking soms onhandig is, hoeven we daardoor iig die ellendige project files niet te mergen).

Thuis gebruik ik volop Git voor mijn Java projecten, sowieso lokaal en ik ga binnenkort ook een remote opzetten op mijn NAS om wijzigingen naartoe te pushen.

Belangrijk om je te beseffen is dat Git een distributed versioning systeem is, terwijl Subversion bijvoorbeeld met een centrale repository werkt. Als je bij Git iets commit, dan doe je dat alleen lokaal. Pas wanneer je een merge doet met een remote kun je hem ook pushen (als er in de tussentijd iets gewijzigd is door iemand anders).

Grote voordeel is dat je helemaal lokaal kunt werken ermee, zelfs al heb je verder niets meer (denk laptop en stroomstoring).

Nadeel is dat het nogal even wennen zal zijn voor de gemiddelde SourceSafe gebruiker

Ik heb trouwens voor mezelf het volgende boek besteld:

http://comcol.nl/rest-api-design-rulebook.html

Om iig een beter idee te krijgen hoe je een REST API hoort te ontwerpen. Ik heb zelf al wat simpele API's gebouwd, maar zodra ze complexer worden moet je toch goed opletten dat je er geen rommeltje van maakt.

En mocht je iets met authenticatie doen, dan raad ik je aan om naar token authenticatie te kijken. Daarnaast zou ik standaard HTTPS gebruiken, zodra je iets qua security nodig hebt.

OReilly heeft trouwens ook nog een ander handig boek: RESTful Web APIs. Die is misschien zelfs nog wel beter om te lezen.

[ Voor 52% gewijzigd door Lethalis op 29-05-2014 12:10 ]