Messing with REST API

WebThings
1

I have started the Gateway and tried to interact through some HTTP requests sent from VScode thanks to REST Client extension.
What happens is that I successfully perform the login and get the jwt object. But then, even though in the request I specified to keep-alive the session, if I try to get something I result as unauthorized.

Some example for the sake of clarity:

  • Request:

    POST http://localhost:8080/login
Connection: keep-alive
Content-type: application/json

{ "email" : "don@joe.com", "password" : "foobar" }

  • Response:

    HTTP/1.1 200 OK
X-Powered-By: Express
Content-Security-Policy: frame-ancestors 'none'
Vary: Accept, Accept-Encoding
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type,
Accept, Authorization
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Surrogate-Control: no-store
Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate
Pragma: no-cache
Expires: 0
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 9
Date: Mon, 28 Nov 2022 23:15:46 GMT
X-RateLimit-Reset: 1669678005
Content-Type: application/json; charset=utf-8
Content-Length: 268
ETag: W/"10c-PhHtPdzblZfpxMeWzPwFM1y8LMg"
Connection: keep-alive

{
    "jwt" : "eyJcCI6IkpXVCIsImtpZCINGNkYi1iMjU2LTBlaefjifijrsnz.eyJyb2xlIjoidXNlcl90b2tlbiIsImlhdCI6MTY2OTY3NzM0NiwiaXNzIjoiTm90IHNldC4ifQ.bBsjWzmL7-Wgv7mIMdcLJ9MrS2pBasdaiefofimskdmk6q4JYAmrPsFQOFzL0nL_qtSIfsWLw"
}

  • Requests:

    GET http://localhost:8080/things/virtual-things-7/properties/on
Accept: application/json
Authorization: { "jwt" : "eyJcCI6IkpXVCIsImtpZCINGNkYi1iMjU2LTBlaefjifijrsnz.eyJyb2xlIjoidXNlcl90b2tlbiIsImlhdCI6MTY2OTY3NzM0NiwiaXNzIjoiTm90IHNldC4ifQ.bBsjWzmL7-Wgv7mIMdcLJ9MrS2pBasdaiefofimskdmk6q4JYAmrPsFQOFzL0nL_qtSIfsWLw" }

###

GET http://localhost:8080/things/virtual-things-7/properties/on
Accept: application/json

###

GET http://localhost:8080/things/virtual-things-7/properties/on
Content-type: application/json

  • Response:

    HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Content-Security-Policy: frame-ancestors 'none'
Vary: Accept
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Surrogate-Control: no-store
Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate
Pragma: no-cache
Expires: 0
Date: Mon, 28 Nov 2022 23:22:50 GMT
Connection: close
Transfer-Encoding: chunked

What am I doing wrong? Suggestions? Better ways to perform these tests?

2

Hi @ninosanta,

The Authorization header needs to take the form:

Authorization: Bearer gdJhbGciOiJFUzIasiIsInR5cCI6IkpXVCIsImtpZCI6ImZjZWI3OGM5LWIyZTMtNGNkYi1iMjU2LTBlNWVlZjAyYmNhMiJ9.eyJyb2xlIjoidXNlcl90b2tlbiIsImlhdCI6MTY2OTY3NzM0NiwiaeedIjoiTm90IHNldC4ifQ.bBsjWdgL7-WYRZfPnVUpgv7mIMdcLJ9MrS2pBFtAXaWvbSU960XInU0jd6q4JYAmrPsFQOFzL0nL_qtSIfsWag

That’s the word “Bearer”, followed by a space, followed by the JWT.

The API is documented here.

No need to log in from the REST API once you have a JWT, since the token acts like a password.

P.S. Hopefully that’s not a real JWT you’re sharing on a public forum.

1 Like
3

Thank you @bfrancis for the help :grin: fixing the Authorization header did the trick.

Now I am facing another newbie problem. In the property resource section of the API documentation there is an example for setting a property value, that basically consists in performing a PUT of the object { "property" : value } toward the property’s link.
In my thing description, I have the following properties object:

"properties": {
    "on": {
      "name": "on",
      "value": false,
      "title": "On/Off",
      "type": "boolean",
      "@type": "OnOffProperty",
      "forms": [
        {
          "href": "/things/virtual-things-7/properties/on"
        }
      ]
    }
  }

When I try to set the value of the “on” property to “true” through the following PUT, I get “Invalid property value” error:

# REQUEST:
PUT http://localhost:8080/things/virtual-things-7/properties/on
Authorization: Bearer hafbhjfbefexsmskxkdmckvrnvrjaewcxshsssamaammxc ekefenfenfjjjxmsk
Accept: application/json
Content-Type: application/json

{ "on": true }

# RESPONSE:
HTTP/1.1 400 Bad Request
X-Powered-By: Express
Content-Security-Policy: frame-ancestors 'none'
Vary: Accept, Accept-Encoding
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Surrogate-Control: no-store
Cache-Control: no-store, no-cache, must-revalidate, proxy-revalidate
Pragma: no-cache
Expires: 0
Content-Type: text/html; charset=utf-8
Content-Length: 22
ETag: W/"16-8B1LpC9EgBpwGkGLbe1uf+1s61I"
Date: Tue, 29 Nov 2022 16:42:25 GMT
Connection: close

Invalid property value

What am I doing wrong? :persevere:

4

For version 1.0 (the latest release) that looks correct.

However, if you’re building the gateway yourself from the master branch (which given the Thing Description you pasted it looks like you might be) then the REST API on that branch is in the middle of being migrated to the upcoming W3C WoT Profile standard instead, which means that won’t work.

In the (draft) W3C standard the writeproperty operation in the HTTP Basic Profile just accepts the value as the payload, without being wrapped in an object keyed by property name.

Try this:

PUT http://localhost:8080/things/virtual-things-7/properties/on
Authorization: Bearer hafbhjfbefexsmskxkdmckvrnvrjaewcxshsssamaammxcekefenfenfjjjxmsk
Accept: application/json
Content-Type: application/json

true
2 Likes
5

Note that the migration to the W3C standard is part way through (the standard is still in draft form) so things are going to be a bit confusing on the master branch for a while.

If you’re interested in the remaining differences from the WoT Profile specification, see the list of issues with the w3c-compliance label on GitHub.

If you want a stable API you may want to check out the 1.0 version instead https://github.com/WebThingsIO/gateway/tree/1.0.0, which still follows Mozilla’s legacy Web Thing API.

2 Likes
6

You’ve got the point: I have built the gateway from the master branch. Hence, the request you suggested worked and the response was compliant with the one documented in the draft (i.e., HTTP/1.1 204 No Content).

Thank you for all the clarifications.

7

Unfortunately, I was not able to build and start the 1.0.0 version of the Gateway on my Ubuntu-aarch64 Virtual Machine running on my Mac having an Apple Silicon processor.
Even what I’ve written here fails on that version.

I guess I will take as a reference the draft and the GitHub issues if necessary, and until some other - hopefully working - attempt to do will pop into my head.