This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-03
Channels
- # aws (5)
- # beginners (67)
- # boot (30)
- # cider (55)
- # clara (7)
- # cljs-dev (6)
- # cljsjs (6)
- # cljsrn (1)
- # clojure (136)
- # clojure-brasil (2)
- # clojure-dusseldorf (14)
- # clojure-finland (9)
- # clojure-italy (49)
- # clojure-nl (1)
- # clojure-romania (6)
- # clojure-russia (4)
- # clojure-uk (16)
- # clojurescript (136)
- # core-async (1)
- # cursive (21)
- # datomic (64)
- # fulcro (26)
- # hoplon (25)
- # jobs-discuss (53)
- # keechma (3)
- # leiningen (6)
- # luminus (11)
- # lumo (2)
- # off-topic (351)
- # om (1)
- # onyx (11)
- # parinfer (32)
- # portkey (9)
- # re-frame (45)
- # reagent (38)
- # shadow-cljs (60)
- # specter (9)
- # vim (8)
- # yada (22)
Buondì, ripresi da pasquetta?
@gabriele.carrettoni anvil.works ?
ultimamente ho lavorato ad una "draft" per uno schema per definire api con edn, stile swagger/openapi, so che sarebbe solo un formato in più ma scrivere a mano json o yaml mi fa stare male
vediamo se riesco ad arrivare a qualcosa di decente, qualcuno ha mai avuto l'esigenza e sarebbe disposto a dare un feedback?
Il mio workflow per tirare su una nuova API: 1. Scrivere la Swagger spec a mano in yaml 2. Da lì generare il server 3. Collegare tutta la logica, db, etc 4. Generare i vari client dalla spec del server (questo lo fa la CI)
Proprio oggi sono alla fase 1 di un nuovo servizio
Forse mi sono perso le premesse, ma compojure-api permette di scrivere clojure+spec per descrivere APIs. Inoltre credo che usando spec-tools si possa generare JSON schema per i vari consumers: https://github.com/metosin/spec-tools#generating-json-schemas (non l'ho mai usato pero')
la premesse è che prima di scrivere una api (a livello di codice) la scrivi in un formato tipo swagger, fai le review con i componenti del team
clojure+spec non va bene dato che non posso chiedere ai miei colleghi di impararsi clojure
@reborg ho usato spec-tools per generare json-schema e funziona molto bene. Ma una volta che stai usando compojure-api ha senso generare swagger (anche perchè i modelli swagger sono espressi in json-schema IIRC)
@gabriele.carrettoni le premesse che abbiamo sono le stesse, è molto comodo avere la visualizzazione Swagger dell’API anche se l’API non esiste ancora, per sanity-check e review.
Per quanto riguarda i “tipi generici” noi non abbiamo problemi particolari, e abbiamo Swagger su un servizio Haskell (che ha un type system un pelo più potente di Swagger). L’assunzione è che i tipi all’esterno devono essere semplici e concreti: liste di oggetti, no oggetti generici tipo { "key" :: String , "value" :: String }
(anche se Swagger è perfettamente capace di esprimerli), etc.
La mia euristica personale è che se è doloroso buttare giù i tipi dell’API a mano, allora probabilmente le data structures che stai passando ai bordi sono troppo complicate, e non saranno simpatiche neanche per i consumer dell’API
@nilrecurring liste di oggetti, se hai una struttura, tipo una lista paginata, è abbastanza ripetitivo dover ogni volta dover ridefinire la parte esterna e poi definire il bean interno, quando magari lo hai già definito da un'altra parte, esempio: GET /requests -> PaginatedList<RequestBean> GET /requests/<uid> -> RequestBean
Ha senso?
GET /request -> [Request]
GET /request/<uid> -> Request
Oh I see
E come chiedi la prossima pagina?
@bronsa peccato, spero nulla di troppo grave!
eh purtroppo non e` una situazione neanche troppo simpatica... ma si fa il possibile
Non sarebbe più "REST" avere tipo /products/page/1
?
e /product/<product-id>
boh, non c'ho mai capito molto delle sintassi REST a dire il vero 😅
vabbe tanto il punto non è quello, non sono api che posso mettermi a scrivere in un modo diverso anche volendo
ahnnn
e comunque non credo sarebbe più rest dato che page non è un attributo di un prodotto
quindi dici GET /products?page=1