0

I've been studying databases and rest APIs lately and I have a question about the relationship between the two.

Imagine I have a database with three tables, STUDENTS, ENROLLED, and CLASSES.

STUDENTS and CLASSES denote the entities students and classes, whereas the ENROLLED table denotes their relationship.

If I were to map this dataset in a rest api, would I just have 3 different CRUD routes with the three tables, eg ('/students', '/classes', '/enrolled')?

And that question goes for REST APIs in general -- when you write/make a REST API, are you just constructing a 1:1 mapping of your database?

Just trying to really nail down my conceptual understanding of the relationship between the two.

gnat
  • 21,442
  • 29
  • 112
  • 288
Jack Damon
  • 119
  • 2
  • ...also, please don't **[cross-post](http://meta.stackexchange.com/tags/cross-posting/info "'Cross-posting is frowned upon...'")**: http://stackoverflow.com/questions/35278128/relationship-between-rest-api-database#comment58267859_35278128 – gnat Feb 08 '16 at 20:24
  • @gnat sorry didn't mean to violate any rules, I posted over there first but someone recommended my post would be better suited here. – Jack Damon Feb 08 '16 at 20:36
  • Also, I'm not asking what the difference between REST & CRUD is. I've read that post and it has some great information but unfortunately not exact what I'm asking. My question is, what is the correct way to structure the relationship between a REST API and a database. Is a 1:1 construction of the database in the API the way to do it? – Jack Damon Feb 08 '16 at 20:37
  • 5
    Actually, the answer to that REST and CRUD question is a pretty good answer to your question as well. – Robert Harvey Feb 08 '16 at 21:09

1 Answers1

0

And that question goes for REST APIs in general -- when you write/make a REST API, are you just constructing a 1:1 mapping of your database?

No.

The database is just an implementation detail.

You can write a bunch of resources that map directly to your domain objects, but that isn't particularly RESTful, in and of itself.

REST isn't about the domain, so much as it is about application state.

If the resources are the application state -- which is to say, if they are analogous to web pages, with links and so on to define for the client what can happen next, that's REST -- but application state probably doesn't look too much like your domain objects (though it may include representations of them in the hypermedia).

On the other hand, if the resources are just loaded by the application state -- if they are analogous to images, where the client learns what images to load by reading the hypermedia, then those routes probably aren't REST. They certainly don't need to be; you aren't telling clients to use these routes, you are telling them to point their browser at a web page that uses those routes.

Once you've got the representation of application state right, REST really doesn't care how you spell your routes, or organize them, or anything. REST only really cares that they are discovered by inspecting the hypermedia.

VoiceOfUnreason
  • 32,131
  • 2
  • 42
  • 79