0

I'm not sure what the most RESTful + HATEOS way is to achieve my goal.

I want to use a PATCH operation to update the fields of two objects, creating a relationship between them, I'm not convinced that the current way I'm doing it is the most RESTful way of doing it.

For example,

I have an API that manages books and authors.

I have an Author entity with a list of Books.

{ "authorId": 1, "email": "[email protected]", "firstName": "f", "lastName": "red", "links": [ { "rel": "self", "href": "http://localhost:8080/authors/1", }, { "rel": "books", "href": "http://localhost:8080/authors/1/books", } } 

and the Book:

{ "bookId": 1, "title": "REST is Hard", "links": [ { "rel": "self", "href": "http://localhost:8080/books/1", }, { "rel": "author", "href": "http://localhost:8080/authors/1", } } 

The above objects are DTOs. I have a Spring Boot backend that manages relationships - this is only relevant in that the actual entity objects look slightly different, and are a bit leaky I think.

Currently, the API will link a book and an author together when it receives a PATCH against http://localhost:8080/author/1/book/1

The API will link author/1 and book/1 - Spring Boot adds the book/1 entity to a list of books in the author/1 entity and sets the author field of book/1 to `author/1' - i.e this is a bidirectional one (author) to many (books) relationship.

Implementation aside (and I think there are still improvements I can make so that the implementation is better), what's the best way of forming this link via a RESTful call?

REST and HATEOS are chatty enough as it is, and I wanted to avoid having to make two URL calls (i.e. one PATCH to author/1 and another patch to book/1) hence http://localhost:8080/author/1/book/1.

Is there a canonically right 'RESTful' way of doing this? How would you implement this?

3
  • I feel like you only need to add a relation to Author on the edited book. What do you think about it? Commented Jun 2, 2019 at 22:20
  • I did think about that @AlbanDericbourg - part of the current approach is actually also laziness now that I think about it. With this request I can just put things in the URL and not have to manage any request body, serialization etc Commented Jun 2, 2019 at 22:44
  • First, the characters and structure of the URI shouldn't be of importance to a client as the URI should be provided by the server anyways and a client shouldn't parse or interpret such a URI to start with. Next, IANA does provide links to registered HTTP methods including links to the RFC proposing these methods. One of these methods is LINK that basically does what you want to do, even though it is defined in an "ancient" HTTP 1.1 RFC Commented Jun 3, 2019 at 1:47

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.