Skip to main content
Software Engineering

Return to Answer

added 5 characters in body
Source Link
Andy
Andy
  • 10.4k
  • 4
  • 28
  • 51

You came upon an operation for which RESTful design simply has not been made. It's a general problem with trying to make an API completely RESTful, and RESTful development should be taken with a grain of salt and pragmatism.

REST and RESTful approaches are good starting points to make your API more predictable. But as evolution goes, you are likely, just like you just have, to encounter a situation in which representing something as a resource does not make a total sense.

You basically have two options:

Follow RESTful practices and forcefully make everything as resource (a noun)

In such case, the best would be to make a new endpoint, POST: /employee/(id)/promotion.

Transform to a more RPC-like approach, where not everything is a resourcenoun

This would be preferable by me, introducing a new endpoint, POST: /employee/(id)/promote.

Know that while current problem might be resolved by noun-ification of the operation, this won't likely be possible for all changes to the system, therefore loosening the rules for your API resource design in most cases proves to be a better, more flexible and easier to work-with approach.

You came upon an operation for which RESTful design simply has not been made. It's a general problem with trying to make an API completely RESTful, and RESTful development should be taken with a grain of salt and pragmatism.

REST and RESTful approaches are good starting points to make your API more predictable. But as evolution goes, you are likely, just like you just have, to encounter a situation in which representing something as a resource does not make a total sense.

You basically have two options:

Follow RESTful practices and forcefully make everything as resource

In such case, the best would be to make a new endpoint, POST: /employee/(id)/promotion.

Transform to a more RPC-like approach, where not everything is a resource

This would be preferable by me, introducing a new endpoint, POST: /employee/(id)/promote.

Know that while current problem might be resolved by noun-ification of the operation, this won't likely be possible for all changes to the system, therefore loosening the rules for your API resource design in most cases proves to be a better, more flexible and easier to work-with approach.

You came upon an operation for which RESTful design simply has not been made. It's a general problem with trying to make an API completely RESTful, and RESTful development should be taken with a grain of salt and pragmatism.

REST and RESTful approaches are good starting points to make your API more predictable. But as evolution goes, you are likely, just like you just have, to encounter a situation in which representing something as a resource does not make a total sense.

You basically have two options:

Follow RESTful practices and forcefully make everything as resource (a noun)

In such case, the best would be to make a new endpoint, POST: /employee/(id)/promotion.

Transform to a more RPC-like approach, where not everything is a noun

This would be preferable by me, introducing a new endpoint, POST: /employee/(id)/promote.

Know that while current problem might be resolved by noun-ification of the operation, this won't likely be possible for all changes to the system, therefore loosening the rules for your API resource design in most cases proves to be a better, more flexible and easier to work-with approach.

Source Link
Andy
Andy
  • 10.4k
  • 4
  • 28
  • 51

You came upon an operation for which RESTful design simply has not been made. It's a general problem with trying to make an API completely RESTful, and RESTful development should be taken with a grain of salt and pragmatism.

REST and RESTful approaches are good starting points to make your API more predictable. But as evolution goes, you are likely, just like you just have, to encounter a situation in which representing something as a resource does not make a total sense.

You basically have two options:

Follow RESTful practices and forcefully make everything as resource

In such case, the best would be to make a new endpoint, POST: /employee/(id)/promotion.

Transform to a more RPC-like approach, where not everything is a resource

This would be preferable by me, introducing a new endpoint, POST: /employee/(id)/promote.

Know that while current problem might be resolved by noun-ification of the operation, this won't likely be possible for all changes to the system, therefore loosening the rules for your API resource design in most cases proves to be a better, more flexible and easier to work-with approach.