I want to have a Post endpoint but two methods in a controller to fire one of them when an API call is received for that.
The point is that the body specifies which method should be fired!
For example, the following one should fire /my-endpoint, but method A
curl 'http://localhost:8080/my-endpoint' --data-raw $'{ "method": "A" }'
And the following one should fire again /my-endpoint, but method B which has different logic than method A
curl 'http://localhost:8080/my-endpoint' --data-raw $'{ "method": "B" }'
Is there any possibility of implementing this in the NestJS?
Is there a problem with parsing the body in a single controller method and at that point invoking the appropriate method? Perhaps in the service?
Failing this, you could look into versioning, since the endpoint url needs to stay the same you could use either media or header options. https://docs.nestjs.com/techniques/versioning#header-versioning-type If the value which dictates which method runs has to be in the body perhaps look at custom versioning.
https://docs.nestjs.com/techniques/versioning#custom-versioning-type
Related
According to the RFC Put is used to update an existing resource.
But, the Stripe API uses Post to update objects. Why is this?
For example, in the Stripe Node Library
update: stripeMethod({
method: 'POST',
path: '{id}',
}),
the update method calls POST
I understand that there is no Patch method since the entire resource must be sent on every call, by why is the Put HTTP Verb not used in that case?
(Unlike this example from an SO question about the Facebook API, the resource is identifiable by a single ID that is passed in the URL) eg the URL is simply /v1/customers/:id
Interesting question! From your link:
The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. 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. [emphasis mine]
This means you must PUT the entire resource (changes and and non-changes alike). Very few APIs are designed that way.
From the spec for POST:
The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource
identified by the Request-URI in the Request-Line. POST is designed
to allow a uniform method to cover the following functions:
Annotation of existing resources;
Many/most APIs have adopted POST as the way to update objects.
Some additional thoughts here: https://stackoverflow.com/a/25909372/379538
When calling an endpoint that is technically creating or updating in the back-end but only requires a single ID to do so
For example:
api/v1/members/1/checkin
api/v1/members/1/checkout
The backend technically only needs the ID from the URL and can do what it needs to do.
I am trying to determine whether I should be making this a GET request or a POST request where the client is responsible for sending a body such as to an endpoint such as: api/v1/members/1/checkin
{
"id": 1
}
I understand this is all preference, but I would like to follow REST standards if possible here.
GET is a 'safe' HTTP requests should not alter the server state, or have side effects.
POST. is more appropriate. If you are passing { "id": 1 } as a body, then PUT can also make sense.
I am using RestSharp to do a REST API client application. If the format of request body (pay load) for a POST Rest Api call is JSON, I would like to know when I should use RestRequest.AddJsonBody() method and when RestRequest.AddObject() method. Thank you.
To send a JSON payload, use AddJsonBody. AddObject will extract name-value pairs from the object and add them as parameters.
We are replicating an existing service and need to offer the exact same contract.
Requests are posted to a single URL with the method name contained in the request body.
For example the request body of a call to LoginService.Login:
All calls will be made to: http://example.com/json
{"id": "","method":"LoginService.Login","params":{"aUserID":"flip","aPassword":"1234-613E-1240-C55D-9853F37A41B2"}}
How can we accomplish this within WCF? The response should also be JSON.
I didn't know what I wanted was called jsonrpc. Luckily somebody already tackled this problem:
Implement JSON-RPC in WCF
I have seen some posts in stackoverflow saying "sending list of items in the GET Method, is NOT allowed. It has to be accomplished via POST method only"
My code looks like
[OperationContract]
[WebGet(UriTemplate = "Employee/{emp}",RequestFormat=WebMessageFormat.Json)]
Employee GetEmpDetails(string emp);
and my input json object will be "{'id':1,'name':'test',....}
Is there any alternative way of achieving this issue.
Thanks
It is possible to send list of items with GET, it's just that out of the box only primitive values are supported. String values work just fine, but if you want to pass a complex object, you need to create a custom QueryStringConverter. The post at http://blogs.msdn.com/b/carlosfigueira/archive/2011/08/09/wcf-extensibility-querystringconverter.aspx explains how this can be done.
If you make your service RESTful you will most probably use HTTP PUT for Add method and HTTP POST for Update method. It is absolutely ok to pass object to these methods because objet will be part of HTTP request's body, not part of URI. URI is important for HTTP GET requests. HTTP GET requests should be only for data retrieval not for data modification.
You are mixing up HTTP GET/POST/... requests and REST GET/POST/PUT/DELETE/...
When you wanna request something RESTfully - you do a GET request. In your case I think it should look like
employee/{id}
or
employee/{name}
Please also note that usage of lowercase in the URI is preferable.
If you need multiple GET criteria, I think it could look like:
employee/id/{id}/name/{name}