Table structure
session
-------------------------
id | name | date
-------------------------
speaker
-------------------------
id | name
-------------------------
session_speaker
-------------------------
session_id | speaker_id
-------------------------
Request methods in place
a) GET /speakers (all speakers)
b) GET /speakers/:id (details on specific speaker)
c) GET /speakers/:id/sessions (list of sessions of a speaker)
Question
What type of request should I make to indicate I need not only the detail of the speaker but also it's sessions, essentially combining results of call (b) and (c) into one.
Also how is it done in real commercial projects? The client makes two calls (b & c) or do they develop another REST endpoint hence combing the results of b & c in a single call?
Or should the client make two requests?
In fact, you could specify as query parameters which fields you want to have within your response payload. Something like:
GET /speakers/someid?fields=firstname,lastname,age,sessions
Another approach (a better one) should be to leverage the header Prefer (see this link for the specification: https://www.rfc-editor.org/rfc/rfc7240) to specify which kind of details you want to have within your response payload:
return=minimal: only the speaker hints
include=sessions: speaker hints and his / her sessions
Here is a sample:
Get /speakers/someid HTTP/1.1
Host: api.example.org
Content-Type: application/json
Prefer: include=sessions
Vary: Prefer,Accept,Accept-Encoding
Irakli Nadareishvili wrote an awesome blog post on this subject: http://www.freshblurbs.com/blog/2015/06/25/api-representations-prefer.html.
Hope it helps you,
Thierry
Related
In OCPP 1.6, the client (Charging Station) sends a CALL (similar to request in HTTP) to server (Charging Station Management Systems). All CALLs have a strict structure of 4 elements:
MessageTypeId (integer)
UniqueId (UUID, string)
Action (string)
Payload (JSON object containing the arguments relevant to the
Action.)
I have gone through the documentation but I cannot find MessageTypeId. So I want to know whether it is just a random number?
Example request payload:
[
2,// <----- I want to know, where I can find this.
"a7caa7a1-c309-43bd-af3f-b5c1c4f9657e",
"Authorize",
{
"idTag": "${req.body.idTag}"
}
]
MessageTypeId Defines the type of Message, whether it is Call, CallResult or CallError:
MessageType | MessageTypeId | Direction
CALL | 2 | Client-to-Server
CALLRESULT | 3 | Server-to-Client
CALLERROR | 4 | Server-to-Client
You can read more on page 9 of This document .
The OCA is authorized site for getting every single documented information for EV related software like different protocol of OCPP.
Link is as below from which you can download all documentation which contains,
Schema of request and response
Defination
Connection details
Structure of Messaging
Details of when to you which request and its meaning
https://www.openchargealliance.org/downloads/
More over, for your query, once you downloaded there is a document named "ocpp-j-1.6-specification" on where page 10 contains official details
Message type OCPP 1.6 from OCPP 1.6 but from this its not means that CALL will be always from client to server. some request CALL are also there which can be initiated from CSMS(Charging station management system) to CS(Charging station)
Thus below is another documented image for same purpose with newer version of ocpp 2.0.1
Message type OCPP 2.0.1 In here its clearly saying that the request will contains CALL to identifying its a request irrespective of source of generation (Either from CSMS or from CS)
I'm trying to make get requested with .Q.hg (HTTP get), but I need to edit the request headers to provide API keys. How can I do this?
You can try this function I wrote a few years back for a POC (similar reason - I needed to supply multiple headers). It's based on .Q.hmb which underpins .Q.hp/hg. Please note - it was never extensively tested & there are likely better alternatives out there, but it will perhaps work as a quick solution.
k)req:{[url;method;hd;bd]d:s,s:"\r\n";url:$[10=#url;url;1_$url];p:{$[#y;y;x]}/getenv`$_:\("HTTP";"NO"),\:"_PROXY";u:.Q.hap#url;t:~(~#*p)||/(*":"\:u 2)like/:{(("."=*x)#"*"),x}'","\:p 1;a:$[t;p:.Q.hap#*p;u]1;(4+*r ss d)_r:(`$":",,/($[t;p;u]0 2))($method)," ",$[t;url;u 3]," HTTP/1.1",s,(s/:("Connection: close";"Host: ",u 2),((0<#a)#,$[t;"Proxy-";""],"Authorization: Basic ",.Q.btoa a),($[#hd;(!hd),'": ",/:. hd;()])),($[#bd;(s,"Content-length: ",$#bd),d,bd;d])}
It takes 4 arguments:
Resource URL
HTTP method
Dictionary of headers
Message body as JSON object
Sending a request to a test server..
q).j.k req["https://httpbin.org/get";`GET;("Content-Type";"someOtherHeader")!(.h.ty`json;"blah");""] // no body so pass empty string
args | (`symbol$())!()
headers| `Content-Type`Host`Someotherheader`X-Amzn-Trace-Id!("application/jso..
url | "https://httpbin.org/get"
I am creating a REST API for the Order screen. I have methods:
GET /api/orders
GET /api/orders/{orderId}
I have some buttons on the Order page and I created few endpoints for that:
PATCH /api/order/buttons/mark-as-read
PATCH /api/order/buttons/change-status
Now I need to add the delete button. But I don't understand how to do that. I have 2 options:
DELETE /api/orders/{orderId} - but I should send 2 additional parameters in this request
PATCH /api/order/buttons/delete - I can send my DTO in the body, but it is not a REST approach.
I want to understand which type of request is used for the delete button in the REST context?
PATCH /api/order/buttons/mark-as-read
PATCH /api/order/buttons/change-status
These are a bit strange. PATCH is a method with remote authoring semantics; it implies that you are making a change to the resource identified by the effective target URI.
But that doesn't seem to be the case here; if you are expecting to apply the changes to the document identified by /api/orders/{orderId}, then that should be the target URI, not some other resource.
PATCH /api/orders/1
Content-Type: text/plain
Please mark this order as read.
PATCH /api/orders/1
Content-Type: text/plain
Please change the status of this order to FULFILLED
Of course, we don't normally use "text/plain" and statements that require a human being to interpret, but instead use a patch document format (example: application/json-patch+json) that a machine can be taught to interpret.
I want to understand which type of request is used for the delete button in the REST context?
If the semantics of "delete" belong to the Orders domain (for instance, if it is a button that signals a desire to cancel an order) then you should be using PUT or PATCH (if you are communicating by passing updated representations of the resource) or POST (if you are sending instructions that the server will interpret).
The heuristic to consider: how would you do this on a plain HTML page? Presumably you would have a "cancel my order" form, with input controls to collect information from the user, and possibly some hidden fields. When the user submits the form, the browser would use the form data and HTML's form processing rules to create an application/x-www-form-urlencoded representation of the information, and would then POST that information to the resource identified by the form action.
The form action could be anything; you could use /api/orders/1/cancel, analogous to your mark-as-read and change-status design; but if you can use the identifier of the order (which is to say, the resource that you are changing), then you get the advantages of standardized cache invalidation for free.
It's normal for a single message handler, which has a single responsibility in the transfer of documents over a network domain, ex POST /api/orders/{orderId}, to interpret the payload and select one of multiple handlers (change-status, mark-as-read, cancel) in your domain.
you offer to use something like this: PATCH /api/orders/{orderId} and OrderUpdatesDto as JSON string in the request body?
Sort of.
There are three dials here: which effective request URI to use, which payload to use, which method to use.
Because I would want to take advantage of cache invalidation, I'm going to look for designs that use: /api/order/{orderId} as the effective request URI, because that's the URI for the responses that I want to invalidate.
It's fine to use something like a JSON representation of an OrderUpdate message/command/DTO as the payload of the request. But that's not really a good match for remote authoring. So instead of PATCH, I would use POST
POST /api/orders/1 HTTP/1.1
Content-Type: application/prs.pavel-orderupdate+json
{...}
But you can instead decide to support a remote authoring interface, meaning that the client just edits their local copy of /api/order/1 and then tells you what changes they made.
That's the case where both PUT (send back the entire document) and PATCH (send back a bunch of edits) can make sense. If GET /api/orders/1 returns a JSON document, then I'm going to look into whether or not I can support one of the general purpose JSON patch document formats; JSON Patch or JSON Merge Patch or something along those lines.
Of course, it can be really hard to get from "changes to a document" to a message that will be meaningful to a non-anemic domain. There are reasons that we might prefer supporting a task based experience, but sending a task centric DTO is not a good fit for PUT/PATCH if you also want caching to work the way I've described above.
I need to create a method in my REST API that will be used to perform some computation. For sake of simplicity, assume that I need to implement a method that for a given list of objects will return its length.
It should only compute the length and return to the client, so no resource will be modified server side. As it does not modify any resources, one would expect that it should be a GET request. However, as the list may be large and the objects may be complex, it looks like I need to make it as a POST request. This would however violate the standard that POST is used in REST to create resources.
What would be your solution to this problem?
First solution
According to RESTful Web Services Cookbook you can treat your computation as a resource and just GET it. For example:
-- Request
GET /computations?param1=2¶m2=2 HTTP/1.1
-- Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": 4
}
It sounds good for fast computations with small amount of input parameters. But if your computation isn't that then you can use second solution.
Second solution
Treat both computation and result as resources. POST computation and GET result. For example:
First you create a computation
-- Request
POST /computations HTTP/1.1
Content-Type: application/json
{
"param1": 2,
"param2": 2
}
-- Response
HTTP/1.1 201 Created
Location: /computations/1
Then you can get this computation
-- Request
GET /computations/1 HTTP/1.1
-- Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"param1": 2,
"param2": 2
}
But also you can get a result (/computations/1/result) of this computation
-- Request
GET /computations/1/result HTTP/1.1
-- Response
HTTP/1.1 204 No Content
Cache-Control: max-age=3600,must-revalidate
But oh no! There is no result yet. Server tells us to come back in an hour (Cache-Control: max-age=3600,must-revalidate) and try again. The second solution allows you to make computation asynchronous (in case when it takes a lot of time) or you can compute it once, store the result in some DB and serve it quickly when requested for the next time.
-- Request
GET /computations/1/result HTTP/1.1
-- Response
HTTP/1.1 200 OK
Content-Type: application/json
{
"result": 4
}
Pragmatic answer: use POST.
Weasely answer: use POST. Your request contains a resource (or set of resources) that you want the server to temporarily create (the list of objects). If the server happens to delete that resource immediately after the POST has been successfully dealt with, what of it?
The moral of the story here is that with REST you always assume a resource, even if in reality one is not needed and likely not created. In the examples above, what if I want to store neither the computation resource (a JSON object that consists of parameters and some sort of operation) nor the computation result resource? I cannot. I can either
Treat this as a fake resource with GET (pretend that it exists) or
Create two resources with a single POST - one for the computation and one for its result - and then use the corresponding GET to retrieve either of those.
A sneaky assumption here also is that there is NO POST for /computation/<computaiton_id>/result because results are only created via computations.
I'm newbie in SIP field. So, please forgive if there is old/easy questions.
Please take a basic call-flow as below to analysis.
phone A -- calls -- phone B -- (transfer to ) -- phone C
A, B, C are extension on same PBX.
Question 1. So, in INVITE message, the History-info will contain:
At B
`History-info : <sip: user A #domain.com>`
At C:
`History-info : <sip: user A #domain.com>`
`History-info : <sip: user B #domain.com>`
`History-info : <sip: user C #domain.com>`
Question 2. And, the PAI header will generate in INVITE message of C
and the format is :
P-Asserted-Identity: <sip:user A #domain;user=phone>.
Question 3. I just want to know when does 2 SIP headers: History-info and P-Asserted-Identity (PAI) occur in SIP message ? and which case ?
Question 4. The difference between 2 SIP headers above and the purpose of them. Are they generated on INVITE message or others ?
Please help me make these concerns clearly.
Q1: Not sure what the question is, but if all UAs (extensions) are sending the calls through the PBX, the PBX may add the History-info fields in any request not associated with an established dialog (INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH, SUBSCRIBE, ..)
Q2: The PAI field should be set with the identity of the calling party, which is still extension A for internal calls. In another scenario, like A is calling B and B is redirected to an outside line, the PAI might be overwritten by the PBX with B's outbound number before the call is sent through the external SIP trunk.
Q3: History-info (RFC4244) is an application specific header field, not always present and most commonly injected by your PBX for internal reasons (checking routing, detecting redirect loops, charging, etc). Being an optional field, its availability and purpose in extensions may vary.
PAI field (RFC3325) contains the identity of the caller.
Q4: Q3 explains the difference between them, PAI holds the identity while histinfo fields are holding the indexed tracking of SIP URIs through which the message passed and any additional info.
PAI can appear in INVITE/OPTIONS/SUBSCRIBE/NOTIFY, for histinfo see Q1.