I am learning REST API and URI design and I have found one here:
https://raw.githubusercontent.com/JeanVEGA/MI-MPR-DIP-Admission/master/examples/requests.sh
I have a few questions.
There is for example:
User.resetPassword, anonymous by User's {email}
curl -i -X POST http://localhost:9090/admission/services/user/person/email:{email}/reset_password
I do not understand construction email:{email}... what does it mean? It means that if I have String path param, I need to do it in this way?
The similar is here:
Term.get
curl -i -H "Accept: application/json" -H "X-CTU-FIT-Admission-Session: [session identifier from User.identity]" http://localhost:9090/admission/services/term/dateOfTerm:{dateOfTerm}/room:{room}
room:{room} - Is this because room should be for example 123ABC? So it is not a number so it need to be written in this way?
And my last question:
User.resetPassword for User by Admission Code, send notification to User's Email and this {email}
curl -i -H "X-CTU-FIT-Admission-Session: [session identifier from User.identity]" -X POST http://localhost:9090/admission/services/user/admission/{admissionCode}/person/email:{email}/reset_password
My poiont of question is "reset_password" ... I thought due to right design principles that no verb should be in URI... because if the verb is in URI, I thought that it means that resource is actually an operation.
That url can be only a resource identifier. So this is an url template which waits a unique email address as a parameter. A filled in template should look something like this:
./person/email:my#email.adr/reset_password
note:
The reset_password is not a valid REST resource (it describes a service not a resource) and the POST method is mostly for resource creation (not for update or partial update). Real REST requests look like this:
PUT ./person/email:{email}/password "newpass"
PUT ./person/{id}/password "newpass"
PUT ./person/email:{email}/identification_factors/password "newpass"
PATCH ./person/email:{email}/identification_factors {password: "newpass"}
and so on...
Related
I'm using "curl -L --post302 -request PUT --data-binary #file " to post a file to a redirected address. At the moment the redirection is not optional since it will allow for signed headers and a new destination. The GET version works well. The PUT version under a certain file size threshold works also. I need a way for the PUT to allow itself to be redirected without sending the file on the first request (to the redirectorURL) and then only send the file when the POST is redirected to a new URL. In other words, I don't want to transfer the same file twice. Is this possible? According to the RFC (https://www.rfc-editor.org/rfc/rfc2616#section-8.2) it appears that a server may send a 100 "with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests without the client asking to send its payload" so what I'm asking for may be thwarted by the server. Is there a way around this with one curl call? If not, two curl calls?
Try curl -L -T file $URL as the more "proper" way to PUT that file. (Often repeated by me: -X and --request should be avoided if possible, they cause misery.)
curl will use "Expect: 100" by itself in this case, but you'll also probably learn that servers widely don't care about supporting that anyway so it'll most likely still end up having to PUT twice...
I'm following Clarifai's guide to make a cURL request and get the tags related to the image.
In the guide it says that I can do either this:
curl "https://api.clarifai.com/v1/tag/?url=https://samples.clarifai.com/metro-north.jpg" \
-H "Authorization: Bearer {access_token}"
or this:
curl "https://api.clarifai.com/v1/tag/" \
-X POST --data-urlencode "url=https://samples.clarifai.com/metro-north.jpg" \
-H "Authorization: Bearer {access_token}"
So what I do is that I type in the access token that I get when I create a new application and I change the link of "samples.clarifai.com" for a random link of a random image, but every time I want to do this I get the following message on terminal:
{"status_code": "TOKEN_INVALID", "status_msg": "Token is not valid. Please use valid tokens for a application in your account."}
Any idea why I keep getting this eben though my access token is right?
Thanks!
Just so there can have an official answer for this but Marcus Müller is totally right.
You should be sure to remove the braces with the Bearer access token. But you still want to be sure everything else is fine. This does assume though that you have generated a proper access token either by the Developer Documentation or within your Applications page once you have logged in.
I configured a REST webservice (a Spring Boot webapplication) on WSO2 AM and used the default /* mapping for resources. My webservice takes an assignee (text) and file parameters.
When I perform the calls, I've noticed that request parameters are not forwarded (HTTP Headers are) to the backed services. For example:
curl -i -X POST -H "Content-Type: multipart/form-data" -H "X-PD20-BillingSubscriptionId: e87d4400-b05f-4f40-9c39-06ae4d28cf4d" -H "Authorization: Bearer rrxRV5F6jdkSBcEPXv7I1yFl2x8a" -F "documentFile=#src/test/resources/sample-files/test-fea-1firma.pdf" -F "assignee=bla.bla#gmail.com" http://api.linksmt.it:8280/fea/1.0.0/signRequest
As you can see, It's a form that posts 2 fields, one of them being a file and another a simple text field.
The call is succesfully forwarded to the backed service but without the actual fields values (the headers instead are correctly passed, though their keys are lower-cased, that is "X-PD20-BillingSubscriptionId" is passed as "x-pd20-billingsubscriptionid").
Any hint on why is this happening?
Thanks
Ok, the problem was the same as described in multipart form data file upload using WSO2 API manger ? and I had to uncomment the declarations for
within the $WSO2_AM/repository/conf/axis2/axis2.xml file (and restart the server).
I would like to stream changes to a Firebase location, but filter the results based on a query to some index, like so:
curl -i -L -H "Accept: text/event-stream" https://mydata.firebaseio.com/path.json?'orderBy="myIndexedField"&equalTo="desiredValue"'
What I observe is that Firebase appears to ignore my query and proceeds to stream all changes to that location whether they match the query or not. Is there any way to do this, other than writing code to perform my own client-side filtering?
EDIT
Frank's answer below shows that Firebase does indeed honor your query parameters. The problem I'm having still persists, and I simply misconstrued what was going on, as the situation turns out to be a little more complicated. I've reproduced my issue in Frank's Firebase, which he was kind enough to supply as a live example for this question.
Here are the steps to reproduce my issue:
Start a streaming query with the constraint type == 1:
$ curl -i -L -H "Accept: text/event-stream" 'https://stackoverflow.firebaseio.com/29265457/.json?print=pretty&orderBy="type"&equalTo=1'
In a separate terminal, post a new item with type==1:
$ curl -X POST -H "Content-Type: application/json" -d '{"type": 1}' https://stackoverflow.firebaseio.com/29265457/.json
{"name":"-JlY1nAmymCKw5lvLvMe"}
This object pops up in my ongoing curl stream as expected, since it matches the query of type==1:
event: patch
data: {"path":"/","data":{"-JlY1nAmymCKw5lvLvMe":{"type":1}}}
Now, here's the part I misinterpreted as Firebase ignoring queries. If I PUT that resource I just POSTed and change it to type==0, it still shows up in my stream! To perform the PUT:
$ curl -X PUT -H "Content-Type: application/json" -d '{"type": 0}' https://stackoverflow.firebaseio.com/29265457/-JlY1nAmymCKw5lvLvMe.json
And here's what I see pop up in my ongoing stream curl:
event: patch
data: {"path":"/","data":{"-JlY1nAmymCKw5lvLvMe":{"type":0}}}
If I PUT "type" to 0 again, it no longer shows up in my curl stream terminal. If I PUT type to 1, then it does pop up in my curl stream (expected). It's the transition from 1->0 where I get the unexpected event.
Also, using PATCH instead of PUT to modify "type" appears to result in the same behavior in the curl stream.
I think it's natural to expect that when I change a value to NOT match my query anymore, I wouldn't see it in my stream. However, it looks like perhaps the query is being matched before the value is edited, or something along those lines... I have no idea how this is implemented on the Firebase end.
So I guess the new question is: How can I avoid seeing changed values that don't match my query in the REST stream?
There are two things that could be wrong here:
you didn't define an index on myIndexedField
your URL is quoted incorrectly
Ad 1) When you access Firebase through the (JavaScript/iOS/Java) libraries, it will fall back to client-side ordering and filtering if you're ordering/filtering data that is not indexed. Given that the REST API doesn't come with a client-library, it cannot perform such a fallback and it will simply return the data unordered/unfiltered.
Ad 2) you need to put your single quotes around the entire URL, not just the query string. An example curl that works for me:
curl -i -L -H "Accept: text/event-stream" 'https://stackoverflow.firebaseio.com/29265457/.json?orderBy="type"&equalTo=0'
I push data to it with this JavaScript snippet:
new Firebase('https://stackoverflow.firebaseio.com/29265457/').push({ type: 0 });
And it shows up in the curl window; or it doesn't if I set type to 1.
I know HTTP PUT is an idempotent request that store something at a specific URI, according to the definition (quoted from the rfc)
The PUT method requests that the enclosed entity be stored under the supplied Request-URI.
But what is the definition of 'enclosed entity'? It doesn't seem possible for me to send form data (like for HTTP POST request) over. What about sending representation of the entity via JSON/XML or in other serialization formats?
In short, how does one send a HTTP PUT request over to store/update info at a specific URI then?
In REST you have:
GET - retrieve resource
POST - create new resource
PUT - update existing resource
DELETE - delete resource
So the PUT verb is used to update an existing resource on the server. Depending on the client there are various ways of sending a PUT request. For example with jquery AJAX:
$.ajax({
type: 'PUT',
url: '/products/123',
data: { name: 'new product name' }
});
The enclosed entity is the payload data contained in the HTTP message body (after any transfer encodings have been removed.) If you're having trouble sending the message body then it could be that you've forgotten to include a Content-Length header - that's one of two ways to indicate that the HTTP message has a body.
PUT is the same as POST except for this semantic difference: With POST the URI identifies a resource that will handle the entity, such as a servlet. With PUT the URI identifies the entity itself, for example a file that will be created/replaced with the contents of the entity body.
So a HTTP PUT request is often issued to replace the currently stored resource at a given URI. For example, there's a book stored at https://example.org/book/1 where the data can be representated in JSON as follows,
$ curl --request GET https://example.org/book/1
{
"title": "Stackoverflow Compilation Book 1",
"year": 2019
}
Suppose someone wants to fix the year field because the fictional book was published last year (2018), he/she would have to send the COMPLETE updated book info over through a HTTP PUT request.
$ curl --request PUT
--header "Content-Type: application/json"
--data '{"title": "Stackoverflow Compilation Book 1", "year": 2018}'
Notice the change in year attribute.
Considering a HTTP PUT request is essentially a replace operation, one can also replace the book represented by the URI to something else. For instance,
$ curl --request PUT
--header "Content-Type: application/json"
--data '{"title": "Some random book that nobody publishes", "year": 2019}'
The attached data can be in any format (usually also specified in the request header Content-Type, as shown above), as long as it is supported, usually reported by Accept response header (which denotes what kind of data type the application is willing to deal with). Further validation would be handled by the application code to determine whether the submitted data is valid.
You send a HTTP PUT where the body is the 'enclosed entity' that you wish to store under the requested URL. Very similar to POST, it is only the semantics as specified in the RFC, that differ.
If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.