3 ms·

Explicitly linking database operations to API calls is idiotic for multiple reasons. First it creates tight coupling, second if you want to do multiple operatio

by adamors 13y ago

Explicitly linking database operations to API calls is idiotic for multiple reasons. First it creates tight coupling, second if you want to do multiple operations at once you have to make multiple calls to the API. That doesn't scale at all. Everyone should be writing their REST back end and the API should be as specialized as possible. One HTTP call should give you back everything you need for a page/view w/e.

drawkbox 13y ago
I agree the article is missing the abstraction all public apis need to offer non changing services. Behind that public front everything can change and routes can be added, if things change majorly you version it. But never is it a good idea to map the db operations directly to the rest urls, so much more has to happen in production. The public api layer is sometimes mapped more manual as auto generation rest apis rarely aren't leaky abstractions. ORMs, data layers, authentication etc behind the scenes may be generated or flexible to change. Public apis might even have public objects that aren't objects from the database in full or at all i.e. meta/tracking fields, private info. Public apis offer multiple levels of service: direct data/json, mvvm views, tools, syncing, per-view state (multiple objects), authentication etc. The term REST has colluded it a bit but ultimately REST is representational state transfer, it doesn't have to be web to db without an application layer. An API is a public definition that should be as concrete as possible for the service use cases and public apis provide a flexible abstraction to expose a service to other consumers. So I will keep writing my public apis, I'll generate boilerplate behind that but I won't be locked to any implementation other than a uniquely designed api for my service, features needed and use case.
- adamors 13y ago
  > it doesn't have to be web to db without an application layer I don't even think it's possible to do that if you have a bit more complicated application. Because every API that does more than the very basic CRUD needs something else besides interfacing with the database.
  - drawkbox 13y ago
    Yes the only time I could see that being useful might be in a private api used by an admin application or similar. But for a public api, prepare for some pain.
spacemanmatt 13y ago
+1 That mega-JOIN that brings back the entire client context is more awesome for db throughput, than plethoras of single-object calls. THIS IS WHY you build an API, rather than exposing CRUD. CRUD is not an API.
- icebraining 13y ago
  A Remote Facade, as Martin Fowler would put it: http://martinfowler.com/eaaCatalog/remoteFacade.html http://martinfowler.com/eaaCatalog/remoteFacade.html

by adamors 13y ago

drawkbox 13y ago

I agree the article is missing the abstraction all public apis need to offer non changing services. Behind that public front everything can change and routes can be added, if things change majorly you version it. But never is it a good idea to map the db operations directly to the rest urls, so much more has to happen in production. The public api layer is sometimes mapped more manual as auto generation rest apis rarely aren't leaky abstractions. ORMs, data layers, authentication etc behind the scenes may be generated or flexible to change. Public apis might even have public objects that aren't objects from the database in full or at all i.e. meta/tracking fields, private info. Public apis offer multiple levels of service: direct data/json, mvvm views, tools, syncing, per-view state (multiple objects), authentication etc. The term REST has colluded it a bit but ultimately REST is representational state transfer, it doesn't have to be web to db without an application layer. An API is a public definition that should be as concrete as possible for the service use cases and public apis provide a flexible abstraction to expose a service to other consumers. So I will keep writing my public apis, I'll generate boilerplate behind that but I won't be locked to any implementation other than a uniquely designed api for my service, features needed and use case.

adamors 13y ago
> it doesn't have to be web to db without an application layer I don't even think it's possible to do that if you have a bit more complicated application. Because every API that does more than the very basic CRUD needs something else besides interfacing with the database.
- drawkbox 13y ago
  Yes the only time I could see that being useful might be in a private api used by an admin application or similar. But for a public api, prepare for some pain.

spacemanmatt 13y ago

+1 That mega-JOIN that brings back the entire client context is more awesome for db throughput, than plethoras of single-object calls. THIS IS WHY you build an API, rather than exposing CRUD. CRUD is not an API.

icebraining 13y ago
A Remote Facade, as Martin Fowler would put it: http://martinfowler.com/eaaCatalog/remoteFacade.html http://martinfowler.com/eaaCatalog/remoteFacade.html