New answers tagged

1

Since you want to persist things on the server between wizard steps, it seems perfectly acceptable to consider each step as a separate resource. Something along these lines : POST /wizard/123/step1 POST /wizard/123/step2 POST /wizard/123/step3 By including hypermedia links in the response, you can inform the client on what it can do after this step - go ...


1

I had needed to do something similar some time ago, and the following describes what we end up with. We have two tables, Item and UnfinishedItem. When the user fills in the data with the wizard, the data are stored in UnfinishedItem table. At each wizard step, the server validates the data entered during that step. When the user is finished with the wizard, ...


1

And that question goes for REST APIs in general -- when you write/make a REST API, are you just constructing a 1:1 mapping of your database? No. The database is just an implementation detail. You can write a bunch of resources that map directly to your domain objects, but that isn't particularly RESTful, in and of itself. REST isn't about the domain, ...


-1

CRUD CRUD is four basic types of SQL commands: Create, Read, Update, and Delete Most applications have some kind of CRUD functionality A CRUD application is one that uses forms to get data into and out of a database REST REST stands for Representational State Transfer.(It is sometimes spelled "ReST") It relies on a stateless, client-server, ...


0

I know how I would do it in a WCF service. class UpdateResponse { int ItemId; ResultType Result; } Class Result { Status //"success" = ALL items were successfully updated //"fail" = At least 1 item in list failed //If status = "sucess" then ItemResponse will be empty //If status = "fail", this will ...


0

How can I create a "New post" button that will send a PUT request? Don't. Not when you are returning HTML. Or is "RESTful creation/deletion" implemented in a totally different way? Slightly the wrong question. REST doesn't care how you do it, beyond the rule that you are using hypermedia controls and media-types. HTTP affords PUT and DELETE ...


1

There are a few reasons why the update of a specific item may fail (e.g., the item has been deleted). The question I'm debating is how to return the result to the caller. Touchstone: how would you do it as a web page? Presumably, the user would start out looking at a web page, with a form on it that would allow her to describe the task -- the jobs in ...


1

First of all, let me say that I agree 100% with @MvdD, that a REST API should not include login/logout semantics. However, as I'm sure you've heard/read OAuth is a headache you really don't want if you aren't "required" to have federated auth! As other answers have pointed out, there is no one pattern to accomplish this, with several being accepted as ...


1

You have two options. Either to use the 200 OK or the 207 Multi-Status. I would not recommend to use the latter, as it is a WebDav status code (WebDav is an extension of HTTP) status code that forces you to respond with an XML document. Although it allows you to use multiple status code in your response. My preference would goes to the 200 OK because it ...


0

I would argue that you should be returning a batch identifier of some sort, and provide another endpoint that the user can call to get whatever information they want about the batch. This would be especially handy if the batch contains a large number of items that take some time to process, as it would enable you to return a 202 Accepted response with the ...


0

You'll probably have a hard time fitting this kind of request in a REST approach, since it is fundamentally aimed at accessing a single resource. That being said, for the response I would simply return 200 OK if some failures doesn't mean global failure, and 409 Conflict if it does. You can put whatever you want in the body of these responses, so better to ...


1

This is a difficult problem. Maybe we can simplify it? Problem with standard paging is that you typically need to know how many are there results in total - so that you can display links to page 1, page 2 ... page X. Maybe you can simplify the UI so that you only have "next" link to the next page - customer doesn't see the total number of results (because ...


1

So what is really a resource, why it should be a mapping to one or more entities and what are some examples? When in doubt about anything relating to REST, consider the question in the context of the web. Here's a flow: I want to read Bob's homepage I know (probably because some other web page told me) that there is a http request handler with the id ...


0

I have some trouble coming up with a way to expose domain model in a resource-oriented manner. You shouldn't be exposing the domain model in a resource oriented manner. You should be exposing the application in a resource oriented manner. if the UI is more command-oriented, which often is the case, then we'll have to map between commands and ...


1

A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). Servers must have the freedom to control their own namespace. Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link ...


5

Typically your REST API should not support login functionality at all. Just require the caller to provide a bearer token from a trusted issuer in the Authorization header and be done with it. Use a well-known authorization provider like Google, Facebook or Microsoft Azure AD as your authorization server. People don't use OAuth because it's mainstream. It's ...


7

GET http://api.example.com/users?usr=username The returned JSON object would contain all the fields for the user (id, password, etc), so I could check the password in the client. Congratulations, you broke the 3 fundamental rules of basic security at once! never store clear passwords never send them over http, but only https never trust ...


2

Sending a password in the parameters isn't just "doesn't look right to me", that's about the worst thing you could do, and I (and everyone else noticing it) would stop using your service immediately due to a brutal security violation. If you send the password back to the client, that is an even worse security violation: Your server must NEVER know the ...


0

data provided by an user is somehow incorrect and could cause my domain object to get into invalid state. So a subclass of DomainException extends RuntimeException is thrown. Perfect. Now: how should I handle this? Suppose my endpoint is used by a frontend and I want to display a proper message to user. Catch the runtime exception at the fault ...


0

HTTP and REST don't care if a resource is a "sub-resource", they have no structural knowledge of a "can't exist without" constraint. From a consistency perspective, if PUT is allowed for a "sub-resource" I would at least expect to be able to GET it separately from its parent resource as well. Then a strict level 3 REST approach (HATEOAS) would also probably ...


4

Consider the first case. Each client gets a random ID that lasts for the duration of the session - which could be several days if you like. Then you store the information relevant to that session somewhere server side. It could be in a file or a database. Let's suppose you pass the ID via a cookie but you could use the URL or an HTTP header. Pros: ...


5

I think you have complexity because you are starting with over-complication: Paths would be something as: companies/1/departments/1/employees/1/courses/1 companies/1/offices/1/employees/1/courses/1 Instead I would introduce simpler URL scheme like this: GET companies/ Returns a list of companies, for each company return short ...


3

Would it be incorrect to consider profile,address,contacts as subresources. No, anything you like can be a subresource. REST doesn't care (a subresource is a resource), and using paths is appropriate URI design for hierarchical elements. is there a completely different option to be considered? You might want edits directed to finer resources ...


4

As is often the case, it depends With a pure JS framework you push a lot of processing to the clients. That means your webserver for the client application will only be serving static files that can be cached. your clients have to be able to handle that processing and need some amount of computing power your clients need to fully support all JS-features ...


0

For pagination, you should be considering the techniques described in RFC 5005. Roughly, each page of results is a separate resource, which itself contains hyperlinks to the previous/next page of results. Then, as usual, the application can just follow the links to navigate from one application state to the next. The actual spelling of the uri doesn't ...


1

I my application, when I create a new person, I use an HTML Now how do I do this with PUT? Where does this go? You don't. If you are using html as your representation of application state, then the links you provide in your hypertext use GET or POST. Yes, you can try to fake PUT/DELETE via post, but the client isn't going to recognize those actions ...


2

In general, you don't want any implementation details exposed in the API. msw and VoiceofUnreason's answers are both communicating that, so it's important to pick up on. Keep in mind the principle of least astonishment, especially since you're worried about idempotence. Take a look at some of the comments in the article you posted ...


4

IMHO, I think you're missing the point. First, the REST API and DB performance are unrelated. The REST API is just an interface, it does not define at all how you do stuff under the hood. You can map it to any DB structure you like behind it. Therefore: design you API so that it's easy for the user design your database so that's it can scale reasonably: ...


2

Isn't this against the RESTFul principle of not using Verbs in the nouns and dealing with Resources instead of actions. No - REST doesn't care about how you spell your identifiers. It's violates URI design guidelines, for exactly the reason you specify -- you are naming an entity (a noun) with a verb. HTTP is already giving you verbs, so you don't ...


5

Neither Format Is REST Standard. REST does not define representation standards. REST does not specify the format of resources. REST is an "architectural style" not a standard. Fielding Dissertation - The Original Document Describing REST It is your application's decision whether to use a hierarchical representation or a flat representation, or to offer ...


3

I assume that you will be using some sort of authentication in your API. Let's say (for argument's sake) that you're providing an API key (GUID) to each user that they put into the HTTP header when accessing this API: GET /employees HTTP/1.1 Host: foobar.com Accept: application/json Content-Type: application/json X-Api-Key: ...


2

But another problem comes with the restful api. I'm not sure what is a good way to expose this kind of data. Any way you like. REST doesn't care, so long as the application state is completely captured in the hypermedia. In particular, REST doesn't care how you spell your URI. Convention is to express hierarchy in the path, and filtering in the ...


1

Every book can have several users as authors and at the same time every user can be an authors of several books. So you have an n:m relationship. No problem, that justmeans you'll need a link table that references both entities. they can also keep this association private Even less of a problem: you add visibility as another attribute to the ...


2

Question 1: Is my thinking correct, is "where to cut the hierarchy" a typical engineering decission I need to make? Maybe - I'd be worried that you are going about it backwards, though. So ok, when returning a company, I obviously don't return the whole hierarchy I don't think that's obvious at all. You should be returning representation(s) of ...


0

For your Q1 on where to cut the engineering decisions, how about picking up the unique Id of an entity that would other way give you the required details on the backend? For example, "companies/1/department/1" will have an unique Identifier on its own (or we can have one to represent the same) to give you the hierarchy, you can use that. For your Q3 on PUT ...


2

As you pointed out, Roy Fielding wrote an interesting article on his blog. And this paragraph summarize pretty well "How to HATEOAS": A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled ...


9

For passwords, sending a hash copy of the password would seem to be your best alternative. Notice that this avoids two of the problems you are considering: the hash of the password disguises the "secret" that you are transmitting, and the result of the hash can be expressed in a reasonable character set so that you don't have to worry about encode/decode. ...


1

Should I rely solely on mongoose's validation for input validation, or should I write my own before it even gets to mongoose? I think that kind of checks should be done by your service, between DB and HTTP modules, not inside DB. For output filtering, should I create a security / filtering module which accepts a Product and returns a ...


0

@VoiceOfUnreason's answer suggests that HATEOAS is really just about links. However, the Programmers StackExchange question @RobertHarvey linked to, What does HATEOAS offer for discoverability and decoupling besides ability to change your URL structure more or less freely?, suggests it's more complicated than that, and HATEOAS includes both using the ...


2

Disclaimer: answer offered without first rereading the Fielding thesis. HATEOAS supports the discovery of previously unknown application states. Think state machine. The hypermedia representation sent to the application describes a current application state, and it describes which triggers are valid transitions out of the state. It doesn't necessarily ...


1

Would it help you to have more resources? /packages/12345/status /packages/12345/status/latest /packages/12345/status/versions/7 /packages/12345/status?at=20150630T1138-0600 /packages/12345/history/delivery/status /packages/12345/history/latest/status /paclages/12345/history/20150630/updates/2 Ceci n'est-pas un package. Different use cases can use ...


0

The Service layer can translate exception received from lower layers to avoid coupling between the controller and the persistence layer. But in doing that translation, the Service layer should not throw away/obscure information that could be relevant for dealing with the reported error. So, the Service layer should in general have a one-to-one mapping ...


0

In most applications, the Service would retrieve the object it needs through the data access layer (effectively loading it in memory) before it can modify it and save it back. If the object doesn't exist, the data access object would probably return null. I would maybe not raise an exception at that point but at least return a specific error case value. The ...


11

The body. Headers are supposed to describe the request, not encapsulate its payload. Headers are meta-data.


2

I've looked at what a request looks like using body parameters and header parameters, and also some PHP examples (thanks to @RobertHarvey) and I've concluded that body parameters are the best way to go, as they do not require any special functions to read in PHP. I was just unsure of what they were, but now I understand completely. POST Body POST ...



Top 50 recent answers are included