I divided my application into the command model and query model.
When the command is executed on the command model, the event is published, and then the query model creates its own data and persists. (it occurs in the same transaction.)
When the user sends data with Post method, the command model has to return created 201.
My question is that is it okay the command model knows about the query model's resource URL?
(is it okay for the command model's controller to be coupled with the query model?)
For example)
Request
Post /articles
body: { title: "the title", body: "the body"}
Response
201 Created
Location: /subscription/news
the UI only reads data from the query model and the query model has some different URL patterns compared to the command model, and they only provide news as a collection.
Is the above example make sense? What do you think?
Putting a reference to the query service's (GET) request in the HTTP response of the command service's (POST) reponse does not imply both services are coupled. Only information about where to find the freshly created resource is stored in the header but the services and their functionality remain separated.
If you want to know more about automatically creating the URL's (I assume you mean hard coded URL by coupling between services) instead of hardcoding them, you could also take a look at HATEOAS...
Related
I am creating a simple CRUD app to learn Azure. I have created a logic app (standard model) and my APIs are designed using the workflow designer. I also have a CosmoDB to hold each object.
My GET API, that gets all the documents, looks like this:
And my GET API, that gets only one document, looks like this:
Here is what my CosmosDB looks like with the ID of the item that is successfully return when statically called:
So what do I need to replace the static ID with, in the *Document ID input so that I can pass in different IDs?
I have looked at the docs and it suggests documentId, but when I type this in I get this error:
Thanks!
Thank you #404 , posting your suggestion as an answer to help other community members.
" You should know the id you want to retrieve from the flow that feeds into the Get a document block (unless it's static). Since you only have a HTTP trigger your id should be supplied through that. As example by passing the id in the url as query parameter which you then refer to in your Document ID field."
Trigger a post request to logic app with Document ID in request body.
Try as below:
I'm quite new to django, i'm trying to migrate and old API built in express to Django Rest Framework,
brief story:
The API is meant to receive different kind of payplods from different device, in example
{
"device": "device001",
"deviceType": "temperature_device",
"deviceTs": timestamp,
"payload": {
"airTemp": X,
"airHum": Y,
}
}
the payload wouldn't be always the same, so other devices (different type) will bring different key - value pairs in the "payload" field.
I'm using Django Rest Framework, alongside model serializers and and GenericViewSet,
but the problem is that before storing the data to the DB and returning the HTTP Response, I need to perform a data validation (minimum, and maximum values) and in some cases, the device sends some "corrupted" data (In example: Negatives number comes with the following syntax: 1.-5 instead of -1.5), I need to fix these values and so on, finally, I need to perform two HTTP request to an external API with the fixed payload and and API Key (that should be stored in the device details model in my database)
so, in short how can I perform any kind of -previous work- to a request BEFORE storing the data into the DB and returning the HTTP response?
You will receive your payload in request.data then you will have to serialize it and validate your payload according to your requirements.
Here is the DRF serilization document which would help you understand how exactly serialization works.
And here is the DRF Validators documents to understand how validators work.
I'm designing a REST API using NodeJS and Express for managing different types of documents (txt, pdf, doc, etc). The document model is something like:
{
id,
category,
name,
path,
tags,
etc..
}
I currently have a route to GET a single document.
/documents/:id
This route serves up the actual document. I would love some guidance on the proper way to serve up the document details (i.e. the name, category, etc). Should I use a different URL? Send details in headers? Use response.format? Make the client specify via query?
Edit: I should clarify that the documents will be stored on the server filesystem and will not be directly accessible by any client.
If the document details are coming from a different source, the most straightforward way is to set up a different endpoint, /document-details/:id.
Otherwise, if a document can be stringified into a JSON, you could nest both in the same response:
{
document: {},
details: {
category,
name,
path,
tags
}
}
I would recommend against sending any detail about document in the HTTP header, those are usually used to send the details about the response itself.
I am new to Solr and PySolr and I am trying to create a web-app. I am planning to use PySolr but when I try to run an example script I get errors. Below are the details:
import pysolr
# Setup a Solr instance. The timeout is optional.
solr = pysolr.Solr('http://localhost:8983/solr/', timeout=10)
# How you'd index data.
solr.add([
{
"id": "doc_1",
"title": "A test document",
},
{
"id": "doc_2",
"title": "The Banana: Tasty or Dangerous?",
},
])
Then I get an error:
pysolr.SolrError: Solr responded with an error (HTTP 404): [Reason: None]
After looking up I found that the URL entered must not be correct, so I changed it to my collection's URL.
solr = pysolr.Solr('http://localhost:8983/solr/#/gettingstarted/', timeout=10)
Now I get the error below:
pysolr.SolrError: Solr responded with an error (HTTP 405): [Reason: None]
HTTP method POST is not supported by this URL
There are tons of questions on the above two errors, but all the resources I found are mostly dealing with some other specific scenarios. So, my question is that how do I give pySolr the correct URL and if the second URL is correct then how to deal with the above error.
The # part of an URL is never sent to the server - it's a local anchor that only the client itself should access. The URL you're using is the admin interface URL that the javascript in the admin interface uses to set up the current page to show.
The core is available directly under /solr, so the correct URL should be http://localhost:8983/solr/gettingstarted/.
You can also see this in the query interface inside the admin interface when making queries (the URL is shown at the top - you're interested in the part without the select handler).
I'm having trouble finding documentation on the request object argument used in replication filters ('req' in the sample below):
function(doc, req) {
// what is inside req???
return false;
}
This old CouchBase blog post has a little code snippet that shows the userCtx variable being a part of the request object:
What is this userCtx? When you make an authenticated request against
CouchDB, either using HTTP basic auth, secure cookie auth or OAuth,
CouchDB will verify the user’s credentials. If they match a CouchDB
user, it populates the req.userCtx object with information about the
user.
This userCtx object is extremely useful for restricting replication of documents to the owner of the document. Check out this example:
function(doc, req) {
// require a valid request user that owns the current doc
if (!req.userCtx.name) {
throw("Unauthorized!");
}
if(req.userCtx.name == doc.owner) {
return true;
}
return false;
}
But the problem now is that CouchDB requires the filter method to be explicitly chosen by the initiator of the replication (in this case, the initiator is a mobile user of my web app):
curl -X POST http://127.0.0.1:5984/_replicate \
-d '{"source":"database", \
"target":"http://example.com:5984/database", \
"filter":"example/filtername"
}'
The Question
Is there a way to enforce a specific filter by default so that users are restricted to replicating only their own data? I'm thinking the best way to do this is to use a front end to CouchDB, like Nginx, and restrict all replication requests to ones that include that filter. Thoughts? Would love a way to do this without another layer in front of CouchDB.
Data replication stands right with user ability to read data. Since if your users shares data within single database all of them has right to replicate all of them to their local couches. So you couldn't apply any documents read restriction unless you've split single shared database into several personal ones - this is common use case for such situations.
There is no any way to enforce apply changes feed filter or other parameters like views has. However, you can use rewrites to wraps requests to some resources with predefined query parameters or even with dynamic ones. This is a little not solution that you'd expected, but still better that nginx and some logic at his side: probably, you'd to allow users to specify custom filters with custom query parameters and enforce you're own only if nothing specified, right?
P.S. Inside req object is very useful about current request. Partially it was described at wiki, but it's a little out of date. However, it's easily to view it with simple show function:
function(doc, req){
return {json: req}
}