2

Currently I'm using a patch route to /api/occurrences/:id that allows a user to update an occurrence. Thing is, I'll need to update the occurrences in many different ways (one to update some data, one simply to change the status and other to update some other data). What would be the best route (as in good pratices) to validate an occurrence per example? I thought about using /api/occurrences/validate/:id when it comes to validating but it is really the best practice?

André
  • 703
  • 1
  • 6
  • 18
  • 1
    https://stackoverflow.com/a/49127862/125816 – Sergio Tulentsev Jul 31 '18 at 10:56
  • Thank you so much, @SergioTulentsev ;) – André Jul 31 '18 at 11:02
  • 1
    Actually, REST architecture doesn't care how you structure the URIs, what is important though is that meaningful relation names and media types are used, otherwise clients couple to an API and therefore will break when the API evolves and changes. By reading through your question I have the feeling that your resource maybe is to large and tries to fulfill to many responsibilities. Maybe splitting it up into more, tinier resources may help you in addressing your issue. – Roman Vottner Jul 31 '18 at 11:02

2 Answers2

0

No, it's not good practice, not because of the URI (as Roman Vottner mentions above, REST doesn't care how you structure your URIs), but because you're effectively creating a RPC method.

Is there any reason why the PATCH to /api/occurrences/:id would not response with a 400 Bad Request and details if validation fails?

Tom Howard
  • 6,516
  • 35
  • 58
  • I'll have different roles and every role will do a different action to the document. Per example, a manager should be able to update the status of a occurrence, therefore we could have a route just for that particular patch since it is a different action from updating the occurrence data. – André Aug 01 '18 at 01:06
  • @André roles and permissions are something internal specific and should not be exposed to the outside world. You are of course free to return different responses for different users/roles depending on the permissions they have. It might be important though to disable caching for those resources as an intermediary cache might server requests not intended for certain users. – Roman Vottner Aug 01 '18 at 11:42
  • @André, part of the problem of using different URLs for different actions is that is complicates cache invalidation. e.g., without extra effort, a patch to `/api/occurrences/validate/:id` will not invalidate `/api/occurrences/:id`. Also from a semantics point of view, the resource you are modifying is at `/api/occurrences/:id`, so that's where you should send your PATCH requests. If you need to support different modification actions, then I would use an extra parameter to specify which action is being performed. – Tom Howard Aug 01 '18 at 23:10
  • @TomHoward Per example, only a manager is able to change the status of an occurrence but both a manager and a secretary can change the normal data of the occurrence. – André Aug 02 '18 at 12:38
  • So /api/occurrences/validate/:id would be used to update the normal data of an occurrence while /api/occurrences/validate/:id would update the status only. A secretary would have access to /api/occurrences/:id but not to /api/occurrences/validate/:id. Does that make sense or should I be doing different? – André Aug 02 '18 at 12:39
  • Do you mean: "/api/occurrences/:id would be used to update the normal data of an occurrence while /api/occurrences/validate/:id would update the status only." – Tom Howard Aug 03 '18 at 06:16
  • 1
    @André The business actions a user can take on a representation returned from a server should be found within a set of links with meaningful link relation names. In your case, when both a secretary and a manager are allowed to change data, provide a link to a kind of formula to these users where they can enter the data and send it to the service. The users aren't really interested in the exact URI but in that the data is transferred to the server. In case of a manager you also can add a link to change the status of the occurrence - this is similar to the (HTML-) Web – Roman Vottner Aug 03 '18 at 11:34
  • @André I believe Roman is talking about something like https://github.com/kevinswiber/siren#actions-1 – Tom Howard Aug 07 '18 at 01:40
-2

Validation of the data should be done by adding the java validation annotations in bean as below : 

@NotNull
private String lastName;
@NotNull
private String firstName;
@NotNull
private LocalDate dateOfBirth;
@NotNull
private Integer siblings;
Saurabh Oza
  • 169
  • 4
  • 18