Hoi,
Post by Marcel van den ElstModels hard aan URLs koppelen koppelen lijkt mij ook een anti-pattern.
Een paar redenen waarom het een anti-pattern is (NB: dit is constructief
Ja, deze discussie helpt mij om te zien wat mensen als bezwaren tegen
Morepath zouden kunnen inbrengen, maar er zijn een paar features in
Morepath die veel van de genoemde problemen helemaal anders kunnen
oplossen -- meerdere apps bijvoorbeeld, zoals we hieronder zien.
Post by Marcel van den Elst# meerdere endpoints voor zelfde model.
Een simpel voorbeeld daarvan is dat je een PersonModel hebt in de backend,
die ontsloten wordt via een ClientResource, UserResource en
EmployeeResource.
Je kunt dit in Morepath op verschillende manieren doen:
* PersonModel met client view, user view, en employee view.
foo_user/client foo_user/user foo_user/employee. Dat zou mijn eerdere
keuze zijn -- models zijn alleen maar een endpoint als ze een view
hebben. Een van die views is de 'default view', de view als je geen
extra /view_name achter de URL plaatst.
* Drie apps, client, user en employee, met daarin helemaal andere
routes, wat je maar wilt. Dus bijv employees/foo_user,
clients/foo_user. Je kunt apps ook in andere apps mounten voor apps
die context nodig hebben.
* een Person model, en dan een ClientPerson, UserPerson en
EmployeePerson. Dit als je erachter komt dat je APIs wezelijk anders
zijn bij het gebruik van Person, en er dus op model niveau eigenlijk
drie models zijn, met hele andere paden. Als dit het geval is kun je
ook tests schrijven zonder over web dingen na te denken.
Post by Marcel van den Elst# wijzigen backend terwijl gepubliceerde API gelijk blijft.
Wanneer jij zelf de enige consumer van je API bent is dit misschien minder
kritisch, maar als derden gebruik maken van je API wil jij niet dat als jij
besluit of genoodzaakt bent om de backend anders in te richten, dat alle
clients (die jij niet eens hoeft te kennen) hun API /moeten/ updaten (of dat
jij dus je backend niet kunt aanpassen).
Natuurlijk is het wijzigen van de code zonder dat de API verandert een
use case. Maar ik zie dat probleem helemaal niet.
Je kunt met de routes gewoon andere models op dezelfde paden zetten.
Je zult de views natuurlijk ook moeten aanpassen.
Je *zou* kunnen beargumenteren dat je met intermediate objecten zoals
resources je views helemaal kunt afschermen van wijzigingen in models,
maar concreet doe je dat toch meestal niet (je hebt bijvoorbeeld
queries in de views). En als je dat wilt doen kun je dat op de model
laag ook doen, en dan heb je het voordeel dat je zo'n facade kan
opbouwen puur op model niveau.
Post by Marcel van den Elst# versioning van de API.
... als je backend gelijkt blijft maar je besloten hebt
Dat is in Morepath goed geregeld; je mount gewoon per API versie een
andere app. Die apps zijn van elkaar geisoleerd, tenzij je expliciet
dingen deelt door ze van elkaar te laten inheriten, of expliciet een
link maakt naar iets in een andere app (of een view hergebruikt).
Post by Marcel van den ElstEn het omgekeerde geval: als je backend gelijkt blijft maar je besloten hebt om de API te veranderen, wil je niet een tweede
backend ernaast hoeven zetten.
Dan verander je toch gewoon de routes? En wat de views doen
natuurlijk. Omdat Morepath automatisch links maakt werken zelfs je
links nog daarna.
Dit soort bezwaren weegt sterker als je aan traversal naar models doet
- de structuur van de models bepaalt de structuur van de URLs. Dan
zijn veel van deze dingen inderdaad lastiger. Maar routing naar models
heeft hele andere eigenschappen.
Groeten,
Martijn