Rest API Best Practice - Single action and Bulk - rest

Let my server have the ability to perform an action called 'A'.
Now, My server needs to have an extra ability to perform bulk 'A' actions.
The route on the server is:
/entity/:entityId/'A'/:'A'Id
Adding the bulk ability faced me with two approaches:
1) Exposing 2 routes to each method:
/entity/:entityId/'A'/:'A'Id and
/entity/:entityId/'A' with a list of 'A' ids in the request's body.
2) Drop the 'A'Id paramater and add a query parameter to the first route called bulk with boolean value:
/entity/:entityId/'A'/?bulk=boolean
And if bulk == true look for 'A'Id[] at the request's body.
else if bulk == false look for id entry at the request's body.
I'm feeling that the 1st approach is better, I'd love to hear thoughts, or maybe a very different approach.
Any opinion is blessed to hear,
Thanks.

Query params are good for GET methods like:
curl -X GET host.com/megacorp/employee?employee_id[]=1&employee_id[]=2
But for POST and PUT methods it's better to use something like this:
curl -XPOST host.com/megacorp/employee/_bulk -d '{"data":[
{"id":"1", "name": "John Doe"},
{"id":"2", "name": "Jane Doe"}
]}'
And to POST or PUT 1 resource - simply provide 1 object in request, like:
curl -XPUT host.com/megacorp/employee/1 -d '{
"name": "JOHN DOE"
},'

Related

Can apiary.io echo back request data?

If I have an apiary.io API described like this:
### Create a User [POST]
+ Request (application/json; charset=utf-8)
{
"user_id": 1053,
"username": "demo#demo.com",
"email": "demo#demo.com",
"active": "true"
}
+ Response 201 (application/json)
{
"user_id": 1053,
"username": "demo#demo.com",
"email": "demo#demo.com",
"active": "true"
}
When I call it from my application and pass it data, it will always pass me back the described payload no matter what data I pass in.
Is there a way to get it to echo back the exact data that I passed in instead of the described payload?
According to Apiary docs/examples you can not, only static request-response mocking. Also you could track this issue.
If you want to use kind of advanced mocks I would suggest you wiremock. It's not so fancy, but way more feature reach. You could run it as a service and update mock mappings at runtime by sending HTTP requests.
Please check solution for your question using wiremock. Related documentation.

Get Reactions using the Github api

Github issues may contain "reactions" for quite a while (as described here: https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments)
I would like to receive that information using the Github api, but there doesn't seem to be anything like that when getting an issue e.g.
api.github.com/repos/twbs/bootstrap/issues/19575
that information does not seem to be inside that response. Also, I did not find another API call that could retrieve that information. How to get those "reactions"?
This is now possible, being the preview state (meaning, you have to pass a custom Accept header in the request). Check out the GitHub API documentation page
Example
$ curl -H 'Accept: application/vnd.github.squirrel-girl-preview' https://api.github.com/repos/twbs/bootstrap/issues/19575/reactions
[
{
"id": 257024,
"user_id": 947110,
"content": "+1"
},
...
{
"id": 888868,
"user_id": 1889800,
"content": "+1"
}
]
The endpoint looks like this:
GET /repos/:owner/:repo/issues/:number/reactions
You can even pass a content parameter (querystring) indicating what kind of reaction you want to retrieve.

Send advanced push notification in parse.com with Rest API

Im trying to send push with two criteria in where.
I make this so:
curl -X POST
-H "X-Parse-Application-Id: myappId" \
-H "X-Parse-REST-API-Key: myRESTApiId" \
-H "Content-Type: application/json" \
-d '{
"where": {“$and”:[{“deviceType": "winphone”},{”channels":{"$all":[“string1”],"$nin":[“string2”]}}]},
"data": {"alert": “String1 is comming”}
}' \
https://api.parse.com/1/push
Something like: https://parse.com/questions/rest-api-or-constraint-on-multiple-fields-using-where, but I getting error message: error code 107 - invalid JSON Parse
How can I send push notification for given device and for given channel with condition $all and $nin.
Thanks for your help!
Hipek
This error is likely being returned because your where value does not match the REST API spec. You will also want to make sure you are consistent in your use of double quotes as these can also lead to malformed JSON errors (e.g. do not use “ and ”, use ").
After fixing that, we end up with the following, which is still not valid per the REST API Parse docs:
"where": {
"$and": [
{"deviceType": "winphone”},
{"channels": {
"$all": ["string1"],
"$nin":["string2"]}
}
]
},
There's a couple of problems with your query:
$and is not a valid Parse REST API operator, and does not appear in the REST API docs. All constraints in a where query are implicitly ANDed, so this is unnecessary, anyway.
Your $all and $nin constraints over channels conflict with each other as there cannot be more than one such query per key. You may want to instead create a unique channel for those installations that should receive messages aimed at the string1 channel but not the string2 channel.

JAX-RS passing parameters to a PUT request

I've heard that in REST world, POST is recommended to create an entry, while PUT is recommended to update an entry.
First, I'd like a confirmation of this statement.
Then, using this assumptions, let's say I have a #POST method to create a user and a #PUT method to update a user (with a #QueryParam to pass the user ID).
What is the correct way to pass parameters to POST and PUT?
Is #FormParam appropriate for #PUT? Or should I pass a JSON in the body?
Should I pass parameters the same way for both #POST and #PUT or a different way?
Or should I use POST for both?
Edit: This question initially showed an example that did not work for me, but it was because my testing tool was doing it wrong. It works with POSTMAN now.
Yes, with REST, you typically use the following:
The method POST of the element list resource to add an element
The method PUT of the element resource to completely update an element
The method PATCH of the element resource to partially update an element
Since what you must send corresponds to the state of the resource, you have to provide it within the request body.
The two bodies (for adding and updating) is similar but there are some differences. For example, if you expect the RESTful service to autogenerate some fields, you don't have to provide corresponding ones.
Here are sample requests:
POST /contacts
{
"lastName": "my last name",
"firstName": "my first name",
}
(corresponding response status code: 201 - Created)
PUT /contacts/contactid
{
"lastName": "my last name",
"firstName": "my first name",
}
(corresponding response status code: 204 - No content)
You can notice that JSON isn't the only format you can use. XML, YAML, and so on could also be used.
I think that the following link could give you some hints:
Designing a Web API - https://templth.wordpress.com/2014/12/15/designing-a-web-api/
Hope it helps you,
Thierry

Difference between XPOST and XPUT

I'm just starting to use ElasticSearch. And I tried to know how to insert documents. I only found examples using the PUT method : $ curl -XPUT 'http://localhost:9200/...'
But it also seems to work using POST. Is there any difference between these two methods?
Thank you.
Generally when using a REST API:
- POST is used to create a resource, where the server will pick an ID.
- PUT is used to update OR PLACE a resource at a known ID.
Doc creation examples in the ES documentation show the caller picking an ID.
Like so:
curl -XPUT 'http://localhost:9200/twitter/tweet/1' -d '{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}'
Since the caller is picking the ID a PUT seems appropriate here.
BUT
using POST Elasticsearch can also generate an ID for you.
$ curl -XPOST 'http://localhost:9200/twitter/tweet/' -d '{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}'
Somehow they have the same functionality with small different
PUT verb (“store this document at this URL”)
POST verb (“store this document under this URL”)
in the put you must indicate the exact URL but in the post you can set document by just type
for example:
PUT /website/blog/123 says put this document at exact this URL but POST /website/blog will insert the document in blog and auto increment the id of the last document.