Skip to main content
Software Engineering

Return to Answer

deleted 8 characters in body
Source Link
Laiv
Laiv
  • 15k
  • 2
  • 34
  • 72

It depends on how you want clients ** to consumeconsume**, interact and discover books and their related resources. Whether a Book should provide clients with more or less data will depend on these things.

When the API is only feeding a single client. Let's say a mobile app or a web app, these apps acts likeact as a lighthouse. Their needs use to dictate which representation suites better to their needs for UX, usability, efficiency, etc.

It's different when we are developing a web API for multiple clients, we have to decide how we want them all to consume thwthe API and how many requests do we want them to do for reaching all the data. Among many other things.

The book's representation of /book/x would be the content offor the page /book/x.page. Everything we deemed necessary for the clients to show the book as we want it to be is there. What's not, can be fetched following the _links o embedded resource's links. In other words, following the links as if it was a web page.

Of course, we could just have returned everything in a single request. However, we would hadhave to weight first the consequences. For example, what happens when we have a collection of Books instead of a single one. How would the server behave with such need of load per book, page, etc. And with high concurrency? What about the database? How would it behave under these conditions? What if we keep adding more info to the book's representantationrepresentation? What if we want to remove related data? What would be less harmful, removing a block of data from book's representantationrepresentation or removing a link?

As you see, there'rethere are so many questionquestions we can not answer for you. That's why is hard for us to say what should you do. It's all up to your needs.

It depends on how you want clients to consume, interact and discover books and their related resources. Whether a Book should provide clients with more or less data will depend on these things.

When the API is only feeding a single client. Let's say a mobile app or a web app, these apps acts like a lighthouse. Their needs use to dictate which representation suites better to their needs for UX, usability, efficiency, etc.

It's different when we are developing a web API for multiple clients, we have to decide how we want them all to consume thw API and how many requests do we want them to do for reaching all the data. Among many other things.

The book's representation of /book/x would be the content of the page /book/x.page. Everything we deemed necessary for the clients to show the book as we want it to be is there. What's not, can be fetched following the _links o embedded resource's links. In other words, following the links as if it was a web page.

Of course, we could just have returned everything in a single request. However, we would had to weight first the consequences. For example, what happens when we have a collection of Books instead of a single one. How would the server behave with such need of load per book, page, etc. And with high concurrency? What about the database? How would it behave under these conditions? What if we keep adding more info to the book's representantation? What if we want to remove related data? What would be less harmful, removing a block of data from book's representantation or removing a link?

As you see, there're so many question we can not answer for you. That's why is hard for us to say what should you do. It's all up to your needs.

It depends on how you want clients ** to consume**, interact and discover books and their related resources. Whether a Book should provide clients with more or less data will depend on these things.

When the API is only feeding a single client. Let's say a mobile app or a web app, these apps act as a lighthouse. Their needs use to dictate which representation suites better to their needs for UX, usability, efficiency, etc.

It's different when we are developing a web API for multiple clients, we have to decide how we want them all to consume the API and how many requests do we want them to do for reaching all the data. Among many other things.

The book's representation of /book/x would be the content for the page /book/x.page. Everything necessary for the clients to show the book as we want it to be is there. What's not, can be fetched following the _links o embedded resource's links. In other words, following the links as if it was a web page.

Of course, we could just have returned everything in a single request. However, we would have to weight first the consequences. For example, what happens when we have a collection of Books instead of a single one. How would the server behave with such need of load per book, page, etc. And with high concurrency? What about the database? How would it behave under these conditions? What if we keep adding more info to the book's representation? What if we want to remove related data? What would be less harmful, removing a block of data from book's representation or removing a link?

As you see, there are so many questions we can not answer for you. That's why is hard for us to say what should you do. It's all up to your needs.

added 141 characters in body
Source Link
Laiv
Laiv
  • 15k
  • 2
  • 34
  • 72

The representation of the resource identified by /books/xIt depends on how you want clients to consumeconsume, interactinteract and discover thediscover books and the relatedtheir related resources. Whether a Book should provide clients with authors`datamore or/and ids depends, mostly, less data will depend on those things.

If you were developing a REST API for multiple clients, you would have to decide how you want them to consume your API and how many requests you want them to do for them to reach all the data. Among otherthese things.

Would be different ifWhen the API would beis only feeding a single client of your own. Let's say a mobile app or a web app. In these cases, these apps actacts like a lighthouse. Their needs use to dictate which representation suites better to their needs offor UX, usability, efficiency, etc.

It's different when we are developing a web API for multiple clients, we have to decide how we want them all to consume thw API and how many requests do we want them to do for reaching all the data. Among many other things.

The business also matters. There could be other concerns to consider. Asconstraints as for example whethersecurity. there'sCan any security concern to take into account before clients go from booksuser have access to the author's data? Can any user list and search authors. Do clients need special grants? Are we going to fetch author's full detailallow guest users to see resources? Or vice-versaYes? How many data are they allowed to see? Can they update resources?, etc.

This isThis's easier to conceptualize with HATEOAS

The previousbook's representation of /book/x would be the content of the page /book/x.page. Everything Iwe deemed necessary for the clients to show the book as Iwe want it to be is there. What's not, can be fetched following the _linksor the o embedded resourceresource's links. In other words. In related pages/resources, following the links as if it was a web page.

Of course, Iwe could just have returned everything in a single request. However, Iwe would had to weight first the consequences. For example, what happens when Iwe have a collection of Books instead of a single one. How would the server behave with such need of load per book, page, etc. Under concurrency. And how wouldwith high concurrency? What about the database server? How would it behave under these conditions? What if we keep adding more info to the book's representantation? What if we want to remove related data? What would be less harmful, removing a block of data from book's representantation or removing a link?

As you see, there's a lot of things that could influence the decisionthere're so many question we can not answer for you. That's why is hard for us to say what should you do. It's all up to your concrete needs and requirements. And also constraints.

The representation of the resource identified by /books/x depends on how you want clients to consume, interact and discover the books and the related resources. Whether a Book should provide clients with authors`data or/and ids depends, mostly, on those things.

If you were developing a REST API for multiple clients, you would have to decide how you want them to consume your API and how many requests you want them to do for them to reach all the data. Among other things.

Would be different if the API would be only feeding a single client of your own. Let's say a mobile app or a web app. In these cases, these apps act like a lighthouse. Their needs use to dictate which representation suites better to their needs of UX, usability, efficiency, etc.

There could be other concerns to consider. As for example whether there's any security concern to take into account before clients go from books to authors. Do clients need special grants to fetch author's full detail? Or vice-versa, etc.

This is easier to conceptualize with HATEOAS

The previous representation of /book/x would be the content of the page /book/x.page. Everything I deemed necessary for the clients to show the book as I want it to be is there. What's not, can be fetched following the _linksor the embedded resource links. In other words. In related pages/resources.

Of course, I could just have returned everything in a single request. However, I would had to weight first the consequences. For example, what happens when I have a collection of Books instead of a single one. How would the server behave with such need of load per book, page, etc. Under concurrency. And how would the database server behave under these conditions?

As you see, there's a lot of things that could influence the decision. That's why is hard for us to say what should you do. It's all up to your concrete needs and requirements. And also constraints.

It depends on how you want clients to consume, interact and discover books and their related resources. Whether a Book should provide clients with more or less data will depend on these things.

When the API is only feeding a single client. Let's say a mobile app or a web app, these apps acts like a lighthouse. Their needs use to dictate which representation suites better to their needs for UX, usability, efficiency, etc.

It's different when we are developing a web API for multiple clients, we have to decide how we want them all to consume thw API and how many requests do we want them to do for reaching all the data. Among many other things.

The business also matters. There could be other constraints as for example security. Can any user have access to the author's data? Can any user list and search authors? Are we going to allow guest users to see resources? Yes? How many data are they allowed to see? Can they update resources?

This's easier to conceptualize with HATEOAS

The book's representation of /book/x would be the content of the page /book/x.page. Everything we deemed necessary for the clients to show the book as we want it to be is there. What's not, can be fetched following the _links o embedded resource's links. In other words, following the links as if it was a web page.

Of course, we could just have returned everything in a single request. However, we would had to weight first the consequences. For example, what happens when we have a collection of Books instead of a single one. How would the server behave with such need of load per book, page, etc. And with high concurrency? What about the database? How would it behave under these conditions? What if we keep adding more info to the book's representantation? What if we want to remove related data? What would be less harmful, removing a block of data from book's representantation or removing a link?

As you see, there're so many question we can not answer for you. That's why is hard for us to say what should you do. It's all up to your needs.

Source Link
Laiv
Laiv
  • 15k
  • 2
  • 34
  • 72

Should, for example, /books/:id return the Book with the given id and the various Authors? Or should it return the Book with the given id and the ids of the various Authors which can then be queried either via a bunch of queries to /authors/:id or /authors?ids=1,2,3, etc.?

Short story long. depends.

The representation of the resource identified by /books/x depends on how you want clients to consume, interact and discover the books and the related resources. Whether a Book should provide clients with authors`data or/and ids depends, mostly, on those things.

If you were developing a REST API for multiple clients, you would have to decide how you want them to consume your API and how many requests you want them to do for them to reach all the data. Among other things.

Would be different if the API would be only feeding a single client of your own. Let's say a mobile app or a web app. In these cases, these apps act like a lighthouse. Their needs use to dictate which representation suites better to their needs of UX, usability, efficiency, etc.

There could be other concerns to consider. As for example whether there's any security concern to take into account before clients go from books to authors. Do clients need special grants to fetch author's full detail? Or vice-versa, etc.

@VoinceOfUnreason already made a good point

Your REST API is an attempt to disguise your domain model as a web site. Let the web be your guide.

This is easier to conceptualize with HATEOAS

{
   "title":"The Jungle Book",
   "published":1894
   "_link":{
        "self":{ "href": "http://myserver/book/x"},
        "authors":{ "href": "http://myserver/book/x/authors"}
   },
   "_embedded":{
         "authors":[
              {
               "name": "Rudyard Kipling",
               "_links:":{ 
                  "self":{ "href": "http://myserver/author/y"},
                  "books":{ "href": "http://myserver/author/y/books"}
              }
         }
   }
}

The previous representation of /book/x would be the content of the page /book/x.page. Everything I deemed necessary for the clients to show the book as I want it to be is there. What's not, can be fetched following the _linksor the embedded resource links. In other words. In related pages/resources.

Of course, I could just have returned everything in a single request. However, I would had to weight first the consequences. For example, what happens when I have a collection of Books instead of a single one. How would the server behave with such need of load per book, page, etc. Under concurrency. And how would the database server behave under these conditions?

As you see, there's a lot of things that could influence the decision. That's why is hard for us to say what should you do. It's all up to your concrete needs and requirements. And also constraints.