Hono: consistent API definitions

Created on 20 Sep 2017  路  3Comments  路  Source: eclipse/hono

From users perspective it, would be nice, if both device registration API and credentials API are defined in the same manner. After a first analysation of both APIs, it turned out that the biggest difference between them is the return code of UPDATE and DELETE operations.

for example:

Device Registration API: updateDevice(...) operation returns status code 200 (ok) and the old registration value (value to be updated).
Credentials API: updateCredentials(...) operation returns status code 204 (no content).

Same difference exists when deleting device registrations and device credentials.

When thinking about equalizing both APIs, the simplest approach would be to let the device registration return 204 (analog to credentials API) on UPDATE and DELETE operation.

That raises two questions, we would like to address in this issue:

  • is there any reason not to equalize both APIs?
  • is there any reason not to change the current device registration API as proposed above?
Device Registry enhancement question

Most helpful comment

The 204 code actually means NO CONTENT and not CREATED (that's 201).
So, the reason why Credentials' update and delete methods return 204 is because they do not include the previous value whereas the Device Registration API's update and delete methods do return it (and thus contain content in the response which requires code 200 instead of 204).

The real question FMPOV would therefore be if we can adapt the Device Registration API's update and delete method behavior to the Credentials API's.

IMHO we should do that because I do not really see much use for the Device Registration API's current behavior and most REST APIs of existing systems do not behave like that as well AFAIC.

@sysexcontrol @ppatierno @pellmann @dejanb
WDYT?

All 3 comments

The 204 code actually means NO CONTENT and not CREATED (that's 201).
So, the reason why Credentials' update and delete methods return 204 is because they do not include the previous value whereas the Device Registration API's update and delete methods do return it (and thus contain content in the response which requires code 200 instead of 204).

The real question FMPOV would therefore be if we can adapt the Device Registration API's update and delete method behavior to the Credentials API's.

IMHO we should do that because I do not really see much use for the Device Registration API's current behavior and most REST APIs of existing systems do not behave like that as well AFAIC.

@sysexcontrol @ppatierno @pellmann @dejanb
WDYT?

Looks like most people are in favor of doing what I proposed, so I will change the Device Registration API accordingly.

Fixed in 764551dcb371497d8196289b1538721e21312a83

Was this page helpful?
0 / 5 - 0 ratings