I have tried,
Websiteurl/posts? _fields=_links,id&_embed=wp:featuredimage.sourceurl
But it only gets the _fields in response and _embedded is missed with the response
Related
I am using mongoose for mongodb and trying to delete a record. A standard REST API should return in a 204 response on delete. However mongoose is returning 200
return await ppc.deleteOne({ _id: id });
With response having deletedCount
data:
deletedCount: 1
status: 200
or using
return await ppc.findOneAndRemove({ _id: id});
returns same 200 with body. Is there any delete API which returns 204 by default?
Like in spring boot or spring data rest it returns 204 by default for a successful delete request. I understand if I need body in response I would need to send 200 for a proper REST API convention. However if I need to return the 204 myself with mongoose, mongo db I would need to check for deletedCount first ,which I can do either on backend or frontend which is a little extra work. I wanted to ensure is there some setting or some other API which defaults it to 204?
Issue with 200 status code is that mongoose even return 200 for a ID which doesn't exists.
You should separate the function of Mongodb as a database vs the HTTP response code your app returns, there is no relation between the two.
200 is the default "success" response code as it's returned because your app successfully executes the code with no errors. mongoose or mongodb are not the ones returning the status.
What it sounds like you want to be doing is incorporate some basic logic into your routes, like so:
const delResult = await ppc.deleteOne({ _id: id });
response.json({statusCode: 402, ...delResult})
With mongoose you can also prebuild triggers to execute after certain operations to handle this type of custom logic for you, that's how you avoid code duplication throughout your app.
I am trying to get list of user paginated
I tried work with this endpoint
GET /admin/realms/{realm}/users
but the response contain all the user.
Endpoint GET /admin/realms/{realm}/users supports pagination (look at method source code)
Just add query params first & max to your request. For example:
/auth/admin/realms/<your realm>/users?briefRepresentation=true&first=0&max=5
P.S. Total records count will be returned in response headers
I have a list of entity IDs that I need to fetch from Dynamics into my application. Using the WebAPI the query must be URL encoded and passed as a GET request which limits the number of entities to about 130 (more than that hits the URL length limit)
Previously we could use the SOAP endpoint to make a single POST request but this is on the deprecation path.
So what is the recommended way to make such a query now?
Some options:
Manually paginate and run through the WebAPI making parallel requests. This is less than ideal, especially when making abstractions around Dynamics since requests may fail.
UPDATE
Thanks to #Guido Preite I was able to use a WebAPI batch request. Basically you issue the GET request with the 130+ entities but encode it in the batch request body to work around the character limit. I'll post the request below for Postman ...
Post to {{myDynamicsURL}}/api/data/v9.0/$batch
Headers
Authorization:Bearer {{token}}
Content-Type:multipart/mixed;boundary=batch_AAA123
Accept:application/json
Cache-Control:no-cache
OData-MaxVersion:4.0
OData-Version:4.0
Prefer:odata.maxpagesize=500, odata.include-annotations="*", return=representation
Body
--batch_AAA123
Content-Type: application/http
Content-Transfer-Encoding:binary
GET {{myDynamicsURL}}/connections?$filter=(connectionid eq 9b704176-2f60-e911-a830-000d3a385a17 or connectionid eq 1ccc526c-2e6c-e911-a831-000d3a385a17 ... <REST OF QUERIES HERE>) HTTP/1.1
Accept: application/json
--batch_AAA123--
you can query using a FetchXML passed inside a POST request
https://dreamingincrm.com/2017/01/15/executing-large-fetchxml-with-webapi/
I'm working with Django REST framework. By default, all the requests returns a JSON object containing the pagination (prev, next, count, results). This is useful in 90% of the cases where the user retrieves or creates info about something. However, there are a few resources which don't have to return anything but rather a confirmation that everything went smoothly - for example, imagine a resource which is just a heartbeat request ("ping") to maintain the session active.
Would it be okay to return a simple response, such as {result: true} (without any pagination like the rest of resources have) or would this be an eventual violation of the REST principles?
If all you want is to know if the URI is fully serviceable, disregarding the body completely, you should simply support a HEAD request instead of GET.
Yes, ouf course such a response to a ping request is OK. Pagination is something only suitable for a collection that can be paged. Paging An unique resource that is not a collection does not make sense.
For the ping request you could even leave the response body empty.
Request:
GET /ping
Response:
200 OK
Content-Length: 0
Pagination should be solved with range headers or hyperlinks. You don't need the body in empty responses, just the status header.
We have a REST API which, for certain operations, we provide the option of asynchronous requests. For async requests, the service will return immediately with a token which can be used to query for completion, while for synchronous requests, the response will not be returned until the operation completes.
The current design for this looks something like this:
URL: PUT /api/orders/1234?async=true
Request Body: customerName=My Company&city=Dallas
Intuitively, it seems wrong to mix query and form params like this, however the query param (async) is providing options to the service call and not an attribute of the resource. That was the primary reason we did not include it in the request body.
Does this approach seem like a good design, or is there a better more "REST-y" way to accomplish the same?
The Prefer header is designed to do exactly what you are trying to do. See the spec.
An URL like this
POST /api/orders/1234?async=true
is not RESTful. Why POST? This looks like RPC over HTTP.
What are your resources? If there is some computation involved, model the computation as resources. POST to a collection of compuations to create a new one. Receive a Location header for the result of the computation.
POST /api/orders
custoerName=My Company
city=Dallas
This could return a response like:
201 Created
Location: /api/orders/1234
Then the client could GET the result:
GET /api/orders/1234
And the server would respond:
200 OK
Some result body.
How to make this asynchronouse?
You write:
however the query param (async) is providing options to the service call and not an attribute of the resource
This is plain wrong. Everything that is in the URI is used to identify the resource. REST is not about calling methods with parameters.
I recommend to always use the two-step-approach described above when modeling compuations/transactions/shopping carts as resources. Create it, retrieve it.