비 REST HTTP 대신 REST를 사용하면 어떤 이점이 있습니까?

비 REST HTTP 대신 REST를 사용하면 어떤 이점이 있습니까?

---

분명히 REST는 HTTP 사용 방법에 대한 일련의 규칙 일뿐 입니다. 이 협약이 어떤 이점을 제공하는지 궁금합니다. 아는 사람 있나요?

---

REST 가 무엇인지 실제로 아무도 아무도 동의하지 않기 때문에 이것에 대한 좋은 대답을 얻지 못할 것이라고 생각합니다 . 위키 피 디아 페이지는 전문 용어 무거운 및 설명에 빛입니다. 토론 페이지는 사람들이 이것에 얼마나 동의하지 않는지 살펴볼 가치가 있습니다. 그러나 내가 알 수있는 한 REST는 다음을 의미합니다.

대신 무작위로 이름 세터와 게터 URL을 갖고 사용하는 GET모든 게터과 POST세터 모두를 위해, 우리는 URL이 자원을 식별하도록 시도하고 HTTP 작업을 사용 GET, POST, PUT그리고 DELETE그들에게 물건을 할 수 있습니다. 그래서 대신

GET /get_article?id=1
POST /delete_article   id=1

당신은 할 것

GET /articles/1/
DELETE /articles/1/

그리고 그 POST와 PUT대응 "을 만들"와 "갱신"작업 (하지만 아무도 어떤 방법 내내 동의하지 않음)에.

캐싱 인수는 일반적으로 캐시 되므로 일반적으로 캐시 문자열 을 사용할 필요가 없으므로 캐싱 인수가 잘못되었다고 생각 합니다. 예를 들어 django는 이와 같은 것을 매우 쉽게 만들고 REST라고 말하지 않습니다.

GET /get_article/1/
POST /delete_article/     id=1

또는 URL에 동사를 포함 시키십시오.

GET /read/article/1/
POST /delete/article/1/
POST /update/article/1/
POST /create/article/

이 경우 GET부작용이없는 POST것을 의미하며 서버의 데이터를 변경하는 것을 의미합니다. 난 당신이 전체 피할 수 특히,이 아마 조금 명확하고 쉽게 생각 PUT일등석 POST일을. 또한 원하는 경우 동사를 더 추가 할 수 있으므로 HTTP가 제공하는 기능에 인위적으로 구속되지 않습니다. 예를 들면 다음과 같습니다.

POST /hide/article/1/
POST /show/article/1/

(또는 어쨌든 예제가 발생할 때까지 생각하기가 어렵습니다!)

결론적으로 볼 수있는 장점은 두 가지뿐입니다.

1. 웹 API가 더 깨끗하고 이해하기 쉬울 수 있습니다.
2. 웹 사이트와 데이터를 동기화 할 때는 말만 synchronize("/articles/1/")하거나 무엇이든 할 수 있기 때문에 REST를 사용하는 것이 더 쉽습니다 . 이것은 코드에 크게 의존합니다.

그러나 나는 꽤 큰 단점이 있다고 생각합니다.

1. 모든 조치가 CRUD에 쉽게 맵핑되는 것은 아닙니다 (작성, 읽기 / 검색, 업데이트, 삭제). 객체 유형 리소스를 다루지 않을 수도 있습니다.
2. 모호한 혜택을위한 추가 노력입니다.
3. 어떤 방법으로 라운드로 혼란 PUT하고 POST있습니다. 영어로 그들은 비슷한 것을 의미합니다 ( "나는 벽에 통지를 게시 / 게시 할 것입니다.").

결론적으로 말하면 : 추가 노력을 기울이고 싶지 않거나 서비스가 CRUD 작업에 실제로 잘 매핑되지 않는 한 두 번째 버전의 API에 대해 REST를 저장하십시오.

---

방금 REST와 관련하여 또 다른 문제가 발생했습니다. 한 요청에서 둘 이상의 작업을 수행하거나 복합 객체의 일부를 가져 오려는 것을 지정하는 것은 쉽지 않습니다. 이는 왕복 시간이 중요하고 연결을 신뢰할 수없는 모바일에서 특히 중요합니다. 예를 들어, 페이스 북 타임 라인에 게시물을 받고 있다고 가정합니다. "순수한"REST 방식은 다음과 같습니다.

GET /timeline_posts     // Returns a list of post IDs.
GET /timeline_posts/1/  // Returns a list of message IDs in the post.
GET /timeline_posts/2/
GET /timeline_posts/3/
GET /message/10/
GET /message/11/
....

어리석은 일입니다. Facebook의 API는 매우 훌륭한 IMO이므로 그들이하는 일을 봅시다 :

기본적으로 쿼리 할 때 대부분의 개체 속성이 반환됩니다. "fields"쿼리 매개 변수를 사용하여 리턴 할 필드 (또는 연결)를 선택할 수 있습니다. 예를 들어이 URL은 Ben의 ID, 이름 및 사진 만 반환합니다. https://graph.facebook.com/bgolub?fields=id,name,picture

I have no idea how you'd do something like that with REST, and if you did whether it would still count as REST. I would certainly ignore anyone who tries to tell you that you shouldn't do that though (especially if the reason is "because it isn't REST")!

---

Simply put, REST means using HTTP the way it's meant to be.

Have a look at Roy Fielding's dissertation about REST. I think that every person that is doing web development should read it.

As a note, Roy Fielding is one of the key drivers behind the HTTP protocol, as well.

To name some of the advandages:

• Simple.
• You can make good use of HTTP cache and proxy server to help you handle high load.
• It helps you organize even a very complex application into simple resources.
• It makes it easy for new clients to use your application, even if you haven't designed it specifically for them (probably, because they weren't around when you created your app).

---

Simply put: NONE.

Feel free to downvote, but I still think there are no real benefits over non-REST HTTP. All current answers are invalid. Arguments from the currently most voted answer:

• Simple.
• You can make good use of HTTP cache and proxy server to help you handle high load.
• It helps you organize even a very complex application into simple resources.
• It makes it easy for new clients to use your application, even if you haven't designed it specifically for them (probably, because they weren't around when you created your app).

1. Simple

With REST you need additional communication layer for your server-side and client-side scripts => it's actually more complicated than use of non-REST HTTP.

2. Caching

Caching can be controlled by HTTP headers sent by server. REST does not add any features missing in non-REST.

3. Organization

REST does not help you organize things. It forces you to use API supported by server-side library you are using. You can organize your application the same way (or better) when you are using non-REST approach. E.g. see Model-View-Controller or MVC routing.

4. Easy to use/implement

Not true at all. It all depends on how well you organize and document your application. REST will not magically make your application better.

---

IMHO the biggest advantage that REST enables is that of reducing client/server coupling. It is much easier to evolve a REST interface over time without breaking existing clients.

---

Discoverability

Each resource has references to other resources, either in hierarchy or links, so it's easy to browse around. This is an advantage to the human developing the client, saving he/she from constantly consulting the docs, and offering suggestions. It also means the server can change resource names unilaterally (as long as the client software doesn't hardcode the URLs).

Compatibility with other tools

You can CURL your way into any part of the API or use the web browser to navigate resources. Makes debugging and testing integration much easier.

Standardized Verb Names

Allows you to specify actions without having to hunt the correct wording. Imagine if OOP getters and setters weren't standardized, and some people used retrieve and define instead. You would have to memorize the correct verb for each individual access point. Knowing there's only a handful of verbs available counters that problem.

Standardized Status

If you GET a resource that doesn't exist, you can be sure to get a 404 error in a RESTful API. Contrast it with a non-RESTful API, which may return {error: "Not found"} wrapped in God knows how many layers. If you need the extra space to write a message to the developer on the other side, you can always use the body of the response.

Example

Imagine two APIs with the same functionality, one following REST and the other not. Now imagine the following clients for those APIs:

RESTful:

GET /products/1052/reviews
POST /products/1052/reviews       "5 stars"
DELETE /products/1052/reviews/10
GET /products/1052/reviews/10

HTTP:

GET /reviews?product_id=1052
POST /post_review?product_id=1052                  "5 stars"
POST /remove_review?product_id=1052&review_id=10
GET /reviews?product_id=1052&review=10

Now think of the following questions:

• If the first call of each client worked, how sure can you be the rest will work too?

• There was a major update to the API that may or may not have changed those access points. How much of the docs will you have to re-read?

• Can you predict the return of the last query?

• You have to edit the review posted (before deleting it). Can you do so without checking the docs?

---

I recommend taking a look at Ryan Tomayko's How I Explained REST to My Wife

Third party edit

Excerpt from the waybackmaschine link:

How about an example. You’re a teacher and want to manage students:

• what classes they’re in,
• what grades they’re getting,
• emergency contacts,
• information about the books you teach out of, etc.

If the systems are web-based, then there’s probably a URL for each of the nouns involved here: student, teacher, class, book, room, etc. ... If there were a machine readable representation for each URL, then it would be trivial to latch new tools onto the system because all of that information would be consumable in a standard way. ... you could build a country-wide system that was able to talk to each of the individual school systems to collect testing scores.

Each of the systems would get information from each other using a simple HTTP GET. If one system needs to add something to another system, it would use an HTTP POST. If a system wants to update something in another system, it uses an HTTP PUT. The only thing left to figure out is what the data should look like.

---

I would suggest everybody, who is looking for an answer to this question, go through this "slideshow".

I couldn't understand what REST is and why it is so cool, its pros and cons, differences from SOAP - but this slideshow was so brilliant and easy to understand, so it is much more clear to me now, than before.

---

Caching.

There are other more in depth benefits of REST which revolve around evolve-ability via loose coupling and hypertext, but caching mechanisms are the main reason you should care about RESTful HTTP.

---

It's written down in the Fielding dissertation. But if you don't want to read a lot:

• increased scalability (due to stateless, cache and layered system constraints)
• decoupled client and server (due to stateless and uniform interface constraints)
  • reusable clients (client can use general REST browsers and RDF semantics to decide which link to follow and how to display the results)
  • non breaking clients (clients break only by application specific semantics changes, because they use the semantics instead of some API specific knowledge)

---

• Give every “resource” an ID
• Link things together
• Use standard methods
• Resources with multiple representations
• Communicate statelessly

It is possible to do everything just with POST and GET? Yes, is it the best approach? No, why? because we have standards methods. If you think again, it would be possible to do everything using just GET.. so why should we even bother do use POST? Because of the standards!

For example, today thinking about a MVC model, you can limit your application to respond just to specific kinds of verbs like POST, GET, PUT and DELETE. Even if under the hood everything is emulated to POST and GET, don't make sense to have different verbs for different actions?

---

Discovery is far easier in REST. We have WADL documents (similar to WSDL in traditional webservices) that will help you to advertise your service to the world. You can use UDDI discoveries as well. With traditional HTTP POST and GET people may not know your message request and response schemas to call you.

---

One advantage is that, we can non-sequentially process XML documents and unmarshal XML data from different sources like InputStream object, a URL, a DOM node...

---

@Timmmm, about your edit :

GET /timeline_posts     // could return the N first posts, with links to fetch the next/previous N posts

This would dramatically reduce the number of calls

And nothing prevents you from designing a server that accepts HTTP parameters to denote the field values your clients may want...

But this is a detail.

Much more important is the fact that you did not mention huge advantages of the REST architectural style (much better scalability, due to server statelessness; much better availability, due to server statelessness also; much better use of the standard services, such as caching for instance, when using a REST architectural style; much lower coupling between client and server, due to the use of a uniform interface; etc. etc.)

As for your remark

"Not all actions easily map to CRUD (create, read/retrieve, update, delete)."

: an RDBMS uses a CRUD approach, too (SELECT/INSERT/DELETE/UPDATE), and there is always a way to represent and act upon a data model.

Regarding your sentence

"You may not even be dealing with object type resources"

: a RESTful design is, by essence, a simple design - but this does NOT mean that designing it is simple. Do you see the difference ? You'll have to think a lot about the concepts your application will represent and handle, what must be done by it, if you prefer, in order to represent this by means of resources. But if you do so, you will end up with a more simple and efficient design.

---

Query-strings can be ignored by search engines.

참고URL : https://stackoverflow.com/questions/2191049/what-is-the-advantage-of-using-rest-instead-of-non-rest-http