Hey guys I am trying to call Docebo's REST APIs and I am finding it hard to understand the method for it. Basically, Calling an API requires you to place an X-Authorization Parameter in the request header. The Docebo documentation on implementing this is just a paragraph that is very confusing to read. A similar question has been asked and answered here :
Docebo - constructing authorisation header
I read the code but couldn't quite grasp the explanation as there was little and the code very difficult for me to understand. I have two questions-
1)What is the X-Authorization parameter?
2)How does one compute the X-Authorization parameter to add to the request header to make calls to the Docebo API?
Detailed explanation of how the code works would be great! Thanks in Advance!
Hey I finally figured it out.
What is the X-Authorization parameter?
It is the parameter that has to be added to the header of the request. This header is used to authenticate the call to an API and the server first checks for this parameter to know whether the call is coming from a trusted source. This kind of requests that have a custom X- headers are called pre-flighted requests that require the sender to first send an HTTP OPTIONS request. The server responds with a list of allowed actions that can be performed. Only if the origin(of the sender) is allowed to have the specific header/Have access to the server resources, the request is actually executed.
How does one compute the X-Authorization parameter to add to the request header to make calls to the Docebo API?
It is as follows :
First take a look at the API documentation of Docebo for the specific API you want to call. It will have a list of parameters that the call requires. Then, you need to have the API keys from docebo handy since both of them are used in generating this X-Authorization parameter.Then proceed as follows :
1)Suppose you have n parameters that the call needs.Do the following :
SHA1 encoding of the following string between the brackets - (param-1,param-2,param-3.....param-n,secretKey).Don't forget the commas! Take the SHA1 hash generated in this step and proceed to step 2
2)A UTF-8 base64 encoding of the following string between the brackets-
(PublicKey:hash from step 1).Again, don't forget the colon! and you will obtain an alphanumeric string.
3) The X-Authorization parameter is - Docebo code(notice the space between Docebo and the code).
4)Add the parameter named X-Authorization to the request header before sending it and you will receive the response.
Hope this helps..
Related
hello I have the following question, I have started to study about the API and RESTful
I hope you can help me.
The Get methods are normally sent via the uri, for example
http: // example / login? name = Xxxx
but each method must maintain the standard of doing what the method indicates.
POST update
PUT insert
GET get
DELEATE delete
but if I have to do a Get but the data is very sensitive to travel in the uri. what should I do? Change it for a Post method so that it travels in the body?
I understand that it has security terms like jwt, but in those cases, what should be done?
I have to do a Get but the data is very sensitive to travel in the uri. what should I do? Change it for a Post method so that it travels in the body?
Yes, that's exactly right.
In theory, there's no reason that we couldn't have an HTTP method that is effectively read only and has a method body; but as of 2020-09 the only registered methods that fit the bill are SEARCH and REPORT, which both have WebDAV semantics that you likely want to avoid.
In the absence of a standard method with the semantics that you need, it is okay to use POST.
One way of thinking about this, is that we are using POST to create a new resource using the contents of the request as arguments; the new resource would have its own identifier which obscures the sensitive data. Then you could use the new identifier to GET the latest representation of the resource any time you wanted.
To that basic idea, we add the idea of returning the representation of the new resource when we create it, and treating that resource as an ephemeral thing that you don't need to store because it "goes away" immediately after use (meaning that subsequent attempts to fetch the representation would 404).
So you might end up with a response that looks like
201 Created
Location: /random-url-that-has-no-sensitive-information
Content-Location: /random-url-that-has-no-sensitive-information
Cache-Control: no-cache
....
According REST API design recomendations, getting user by id must be
GET /users/{id}
How will look getting user by unique phone number?
GET /users/phone/{number}
or
GET /users/?phone=xxxxxxxxxxx
or
GET /phones/{number}/users
or anything else?
Or for example getting last user comments with limitation:
/users/{id}/comments/limit/{limit}
or
/users/{id}/comments/?limit='xx'
There are constraints or recomendations in such cases?
Which HTTP method is better to send request for making some actions (for example SMS sending).
There are a lot of different aspects in your question, so I am picking some and hope the answer is somewhat helpful to you.
Generally speaking, a URI ist he unique identifier of a certain ressource. Further more, "good REST-API URIs" contain only nouns (to 'name' the resource), not verbs (what should be done with the resource). URI parameters may be used to parameterize the ressources representation, e.g. sorting or filtering.
In your example,
/users/{id}/?limit='xx'
would be a valid way to fetch a list of some sub-ressources (possibly the users comments), but here is nothing on the URI that refers to a specific property or sub-ressource (e.g. comments).
A more meaningful ressource URI would be
/useres/{id}/comments/?max=100&sort=asc
In this case, the first part (users/{id}/comments/) identifies the ressource, while the params are used to parameterize its representation. Proper URI's do not rely on URI params to uniquely identify ressources.
Filter criteria in the URI may be treated similiar. You could put them in parameters, but that may lead to problems with multiple and/or complex filters, e.g.
GET
/useres/?phone=1234&phonemode=startswith&name=foo&namemode=contains
One way to do this could be to create a filter (maybe just temporarily) and then retrieving the filtered information with a subsequent GET request like this:
POST /users/filter
name='mycomplexfilter'
poperty='name'
value='foo'
mode='contains'
GET /useres/filter/mycomplexfilter
Hope this helps to shed some light on the topic
[EDIT]
See this summary for an explanation of the commonly used HTTP methods (aka verbs): Which HTTP methods match up to which CRUD methods?
See this question for a similiar answer.
Initiating a server sent notification (perhaps via SMS) should be requested using POST (e.g. to the ressource URI /notifications) with text and recipient in the payload. HTTP headers could be used to indicate the desired type of the notfication, while the HTTP status codes indicate the success of the sending attempt. Status code 201 indicates successfull sending of the message, returning also the URI for the newly created ressource.
Client request:
POST /notifications
recipient="+0049123456789"
text="this is the SMS text"
Server response:
201 - Created
Location: /notifications/9876
I'm trying to work with JMeter to test some web services. So far so good, but I was wondering if you could do the following -
I make a http POST request to create a resource, and if successful the response comes back with the location of the resource in the headers. What I would like to do is take the value of this header, and use it in a http GET request to retrieve the resource. Is this possible with JMeter?
Any help is much appreciated
Use the regular expression extractor to extract the header value to a variable by using a regex. Then use the variable like any other variable in your GET request.
Example:
URL: http://example.com/collection/a%20search%20term
Method: GET
Response: All items in collection matching a search term.
Problem: The search term may be so long that it breaks the web server's maximum
URL length.
How do I allow extremely long search terms and still stay RESTful?
For inspiration, I just looked at Google Translate's API v2, which is "using
the RESTful calling style."
Naturally, texts to be translated can be quite long. And so Google optionally
allows sending a request with POST, but with a twist:
To use POST, you must use the X-HTTP-Method-Override header to tell the
Translate API to treat the request as a GET (use X-HTTP-Method-Override:
GET).
So it is possible to semantically transform a POST request into a GET request.
(This discovery led me to add the x-http-method-override tag to my question.)
REST does not restrict POST to creation. Be careful with mapping CRUD to HTTP methods and assume that's RESTful. POST is the method used for any action that isn't standardized by HTTP.
Since the standard doesn't establish a limit for URIs, this can be considered a broken implementation, and it's ok to fix it. As long as the workaround is loosely coupled to your API, you are still RESTful. This means your API shouldn't implement a translation or override directly, but on a pre-processor of some kind that rewrites the request properly. It should be clearly documented somewhere that this is due to a broken implementation, and you expect it to eventually become obsolete.
It's a bad smell if your query can be so long that it exceeds the maximum length (de facto for browsers is 2000 characters but it can be higher for other means of accessing REST APIs).
If the user can pass in that much data, it should go in the request body/data field, not in the URL.
i've been researching/creating a REST api, in the backbone.js to php context.
i understand the concept of HTTP verbs and when they should be used
GET - select
POST - create
PUT - update
DELETE - delete
i also understand the concept of passing an identifier as a semantic url, e.g.
GET http://api/users/123
DELETE http://api/users/123
in these cases the "123" is the id the business logic will use to get/delete a user.
but what about the POST and PUT contexts? when sending a request to
PUT http://api/users/123
the api will update user id 123 with the supplied parameters, here's where my question arises.
i would assume the input parameters to update with would be sent as PUT parameters. in php syntax this is represented as: file_get_contents('php://input') (this is the same for delete requests.)
when testing this via backbone.js it works perfectly.
but when i try and create a new element with
POST http://api/users/
i would assume the input values would sent as POST parameters/ in php syntax this is represented as $_POST. but this does not work.
after some testing, and reading up on rails style REST apis (which is what the backbone docs suggest), i realized that all request variables are sent the same way. if i change my code to use file_get_contents('php://input') to get the request parameters for every request type, backbone works perfectly.
is this standard fair for REST apis? or just "rails flavored" ones?
PUT, POST, PATCH, etc (everything but GET and DELETE*) accept request bodies. Generally data is passed as either:
A URL encoded string of name/value pairs (exactly the same as a URL querystring) that is decoded and parsed by the server into $_POST (or similar depending on your web framework of choice). This typically relies on the presence of a Content-Type header set to application/x-www-form-urlencoded (browsers do this by default when forms are submitted). If you see the data in file_get_contents('php://input') but not $_POST it's very likely this header is not present or is set to another value. If you're using Chrome, you can see what headers and body the client is sending in the Network tab of the dev tools.
The other popular request body format is to use Content-Type: application/json and then write out a JSON string to the body. This can be accessed via file_get_contents('php://input') and then parsed with a JSON parser.
* Note on DELETE: it's a little unclear whether or not using a request body with DELETE is allowed or a good practice.